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ABSTRACT 


The Civil Engineer Corps (CEC) is a relatively small Navy community consisting 
of approximately 1300 officers. Billet locations for the CEC range from Bahrain, Saudi 
Arabia to Keflavik, Iceland. CEC officers have a broad range of professional skills 
including contract management, public works management, Seabee operations, and other 
various fields. The infonnation associated with these fields is abundant, and a common 
point of reference would be beneficial to all members. The community is wide spread 
and requires the ability to disseminate information as efficiently as possible to all comers 
of the world. Currently, information resources are available in both print and electronic 
forms in numerous locations. This thesis explores the concept of providing a single on¬ 
line location where CEC officers can go to access the information they need. 

This thesis provides a summary of the development of a working prototype web 
portal, which grants the community access to the vast amounts of information available. 
The intent of the thesis is to explore the possibilities of how modem web-based 
technologies can be leveraged to provide a wealth of information to hundreds of officers 
around the world. In addition to the web development necessary for this prototype, the 
project also includes the development of the relational database to deliver data to the 
portal. 

The research focuses on the methodology used to develop this portal prototype. 
The methodology used for the development of the project is a form of Rapid Application 
Development (RAD) including the following phases: definition, requirements, design, 
and implementation. Rapid Application Development is an iterative method of delivering 
an end product. The method focuses on delivery of small pieces of the whole and builds 
up to the final deliverable in an iterative fashion. 

The completion of this thesis project demonstrates that a community portal is 
viable concept for information delivery to the entire Civil Engineer Corps. The results of 
this thesis can be used to pursue implementation of a similar concept for use by the entire 
community. 
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I. INTRODUCTION & BACKGROUND 


A. AREA OF RESEARCH 

The Civil Engineer Corps (CEC) is a small Navy community consisting of 
approximately 1300 officers. CEC duty assignments are focused in three main areas: 
Seabee Construction Battalions, Contract Management, and Public Works Management. 
Members spend from eighteen months to three years on station at each duty assignment. 
Billet locations range from Bahrain, Saudi Arabia, to Keflavik, Iceland, and virtually 
every Navy and Marine Corps base in between. Moves are frequent, and job descriptions 
vary greatly. The information available to support this community and its many job 
descriptions is vast and wide spread. Currently, there is no single point of delivery for all 
of this information. 

Advances in technology that have occurred over the last decade have made 
information delivery a much easier task. A substantially large portion of the population 
is likely to go straight to the internet when they want to find information on any subject. 
The global nature of the internet means that there are not too many places that you go 
where you cannot find a way to “get online” to access this vast infonnation resource. 
The number of internet hosts is still growing at an amazing rate. (Zakon, 2002) The 
World Wide Web cannot be ignored as a means of information delivery. 

Given this powerful information delivery tool, the Civil Engineer Corps has the 
opportunity to take advantage of a powerful infonnation network that already exists. The 
community is in need of a central access point for all community-related infonnation. 
Cunently, the infonnation is available in different locations and in different forms 
including web pages and print documents. New junior officers coming into the Navy 
need to have one location where they can go to find resources to help them develop their 
careers as CEC Officers. Senior officers, reporting to a specific job type in which they 
have not worked for several years, need a place to go to find the information necessary to 
renew their education in the specific area of the billet to which they are assigned. 
Personnel in the CEC detailing shop need a point of communication with the entire 
community. All community members need the ability to search for both personnel and 
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billets based on current information maintained by the detail office. The internet 
provides the capability to consolidate this information. The creation of this centralized 
resource could provide timesavings to all the officers in the community, as well as to 
community managers, who can go to a single location to deliver news and information. 
The concept of a centralized portal for the community is a viable option for 
accomplishing this task. The portal would initially act as an information delivery tool but 
could also set the stage for the future use of the portal as a resource sharing and 
collaboration tool. 

B. RESEARCH ISSUES 

The primary objective of this research is to explore the possibilities that the 
internet provides as an information delivery tool and to develop a proof-of-concept 
prototype showing the potential for a community portal. The research will focus on 
developing an appropriate delivery tool for the information available. Delivering large 
amounts of infonnation in a single location can often overwhelm a user. The design of 
the portal must balance quantity with quality of delivery. Other portals will be evaluated 
for effectiveness during the development process. 

Another critical issue to be considered is the design methodology to be used. 
Quick delivery of this prototype is essential, and the method chosen to develop it will 
affect the possibility of quick development. Options considered include a classic 
waterfall approach, a spiral methodology, an incremental approach, or rapid application 
development. Rapid application development will be used as it incorporates the best 
aspects of the other methodologies into a single approach. (Osmundson, 2002) 

A final issue of great importance that must be studied is the data model necessary 
to support the delivery of this information. This is of utmost importance and will 
consume a large portion of the project development. The infonnation to be delivered via 
the portal includes personnel infonnation, infonnation resource links, billet infonnation, 
news, awards, and other infonnation as discovered throughout the development of the 
project. This infonnation is highly suited for database delivery. The research will 
concentrate heavily on the development of a data model appropriate for the support of 
this data. 
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c. 


SCOPE 


The scope of this thesis is two-fold. The end goal of the project is to deliver a 
working prototype of this portal concept and evaluate the web as an information delivery 
tool. In order to accomplish this goal, the work will be split up into two sections. The 
first major area of focus will be the relational data model. The model will support the 
development of the working Microsoft Access database to support the functional 
prototype portal. Information contained in the database will be of numerous types 
including, but not limited to, personnel information, billet information, news updates, 
community awards, and information resource links. The second major focus area of the 
thesis will be the development of the working prototype portal and integration with the 
database mentioned previously. The thesis will demonstrate the viability of the 
community portal concept and open the door for the future exploration of such a project. 
This thesis will not include the implementation of the community portal for use by 
members of the Civil Engineer Corps; however, it will investigate the issues associated 
with such an effort. 

D. METHODOLOGY RESEARCH 

Determining a development methodology is critical to the success of any 
information systems project. In order to detennine a proper development method for this 
project, a brief review of the three primary development methodologies is provided 
below. A system development life cycle (SDLC) is a logical process by which 
developers build infonnation systems to solve business problems and/or needs. A 
methodology is the physical implementation of the life cycle, and a true methodology 
should encompass the entire SDLC. (Whitten, 1998, pp. 72-73) The three 
methodologies to be considered are Waterfall, Incremental, and Spiral. This is not an all- 
inclusive list. Rather, it is a list of general development categories. The strengths, 
weaknesses, and implied risks of each will be considered. An extensive list of modem 
development methodologies can be seen at 

http://www.itmweb.com/methodology/wmethod.htm . 
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1. Waterfall 

a. Strengths 

• The waterfall method is the quickest and most straightforward method 
by which to obtain a product. 

• From a manager’s point of view, the waterfall design methodology is 
easier to manage because of its linear nature. 

b. Weaknesses 

• Because of the simple, straightforward nature of the waterfall method, 
it has limited flexibility throughout the design process. This creates a 
need for specific, concrete requirements determination at the 
beginning of the project. 

• In addition, the waterfall methodology does not lend itself to 
segmented systems development. 

c. Implied Risks 

• If requirements are not well defined, the project could fail due to lack 
of direction, because its linear nature does not allow for course 
changes. 

• If a system is large and cumbersome with many parts, this method is 
likely to fail because of its inability to deal with segmented systems. 

2. Incremental 

a. Strengths 

• Incremental design methods provide some additional level of 
flexibility during the design process. 

• This flexibility and the non-linear nature of this methodology make it 
better suited to larger, segmented systems. 

b. Weaknesses 

• Because of the iterative and flexible nature of incremental methods, 
development using this method tends to be more time consuming. 

• Requirements need to be firm but not concrete in order to use this 
design methodology because, although less rigid, it has limits to its 
flexibility. 

c. Implied Risks 

• In a project with fixed time duration, this method can lead to failure 
due to its iterative nature, which is time consuming. 

• Requirements that are not concrete can lead to project failure because 
the method is not infinitely flexible to change. 
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3. Spiral 

a. Strengths 

• Spiral design and development methodologies allow the most flexible 
process for software creation and implementation. 

• This methodology is non-linear and iterative in nature, which makes it 
ideally suited for large multi-part systems without concrete 
requirements. 

b. Weaknesses 

• The fact that requirements do not have to been well defined for this 
process tends to make this the most costly method of software 
development because of the many changes in direction throughout the 
project. 

• Both of the strengths listed for this methodology also lend to its 
weakness, in that, they cause the development process to be long and 
drawn out. 

c. Implied Risks 

• The flexible nature of this evolutionary methodology allows for the 
possibility of both cost and schedule overruns. 

• User interaction in the iterative development process is critical and if 
insufficient could cause project failure. (Sorensen, 2002) 

4. Other Methodologies 

The previous section discussed general design methodologies available for 
development. In addition to these, numerous methodologies are variations of the 
aforementioned. A short sampling of these other methodologies include Rapid 
Application Development, Component Assembly Model, and Concurrent Development 
Model. This is by no means a comprehensive list as the number of methodologies is very 
long. New unnamed processes are created often, because often no one methodology suits 
the needs of the development team. (Osmundson, 2002) 

E. METHODOLOGY SELECTION 

In any information technology project, the method of development can be critical 
to the success of the project. A form of Rapid Application Development (RAD) has been 
chosen as the methodology for this project because of its quick delivery time and focus 
on iterative development of small individual parts of the whole project. (Creative Data, 
2002) Rapid Application Development is not as clearly defined as some other 
development methodologies. There are a few basic principles: joint design teams, 
integrated computer-aided software engineering tools, and an iterative process. The 
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focus of RAD is fast, iterative development. (Harris, 1997, pg. 1-1) Small portions of 
the project are incrementally developed with the result being a complete and usable 
product. Rapid Application Development has the strength of a classic waterfall 
methodology with its structured development phases, but it also has the advantage of 
iterative design phases similar to a spiral approach. 

The methodology to be used is being called a form of RAD because it does not 
follow the basic principles very closely. Joint development teams will not be used 
because a single person is doing the development; and CASE tools will not specifically 
be used since the project is to be delivered as a web product and is relatively small. The 
tools used for this development are discussed in the next chapter. As was mentioned 
previously, design methodologies are very numerous and often modified to fit the needs 
of the project. However, follow-on work to this project could utilize the additional 
principles of RAD more closely as the magnitude of the project would be much greater. 
This development will be broken up into four phases: definition, requirements, design, 
and implementation. A graphical representation of the methodology to be used can be 
seen in Figure 1. 
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Figure 1. Development Methodology 

The definition phase is focused on identifying the users of the system, 
determining the need for the project, and identifying major functional areas of the system. 
The requirements phase will be used to determine specific requirements of the system. 
The entity relationship diagram to support the portal will be developed during this phase 
in addition to a general site plan for the portal. 

The design phase will include the development of the database schema, including 
all entities and their attributes. It will also include the detailed site plan for development 
of the portal. This phase is iterative and often overlaps and interacts with the 
requirements phase. Interaction and repetition between the requirements and design 
phases is what separates this methodology from a traditional waterfall development 
process. During the multiple requirements and design phases, the project will progress 
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from a paper concept to a working prototype through development cycles for each part of 
the system including the database and individual segments of the portal. Each iteration of 
requirements analysis and design will focus on an area of the project and work towards 
the end goal of a single integrated system. 

Since RAD methodology is being used, iterative development is essential. The 
requirements and design phases will be repeated as necessary to accomplish the 
development of each segment of the project. An initial focus will be placed on defining 
the general requirements, and they will be re-evaluated during each phase of the 
development. 

The implementation phase deals with the final details of the project. It involves 
the actual activation of the prototype system and the issues involved in making it a 
successful evolution. Final troubleshooting of the integrated system occurs during this 
phase. This phase will be limited in scope for the purpose of this research, as this is only 
a prototype development. 

Overall, this methodology should provide a quality product in the shortest amount 
of time. Rapid application development is a quick methodology, but this does not mean 
taking shortcuts. (U.C. Davis, 2002) It merely means efficient use of time. Planning is 
still critical to the success of the project, and the following chapters will focus on the very 
important task of requirements determination. 

F. ORGANIZATION 

This thesis will be organized in the following manner: 

1. Chapter I - Introduction 

This chapter introduces the goals of the research and details the methodology to 
be used for the development of the project. 

2. Chapter II - Project Definition 

This chapter will deal with the need for the project, identification of users, and 
major functional area determination. 
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3. Chapter III - Project Requirements & Design 

This chapter is where the project begins to take shape and is the focus of the 
research. Specific requirements will be identified for the prototype system. It deals with 
the actual development of the data model including all entities and attributes as well as 
the web interface creation. The chapter will be divided into 5 development phases, which 
will be defined in more detail later. 

4. Chapter IV - Project Implementation 

This chapter is limited in scope. Two primary issues will be addressed: the final 
integration of the database and web portal and factors to be considered for 
implementation of a similar concept for use by the entire community. 

5. Chapter V - Conclusion 

This chapter summarizes the project and recaps lessons learned, in addition to 
recommending areas of future study. 

G. BENEFITS 

The Navy as a whole is experimenting with the use of portal technology. Naval 
Facilities Engineering Command is specifically working on a portal concept to support 
the entire NAVFAC community. This research will provide ground level insight into 
some of the issues associated with developing an infonnation delivery tool. This research 
will be useful in adding to the collective knowledge of the community concerning web 
and portal technology. The product will provide the Civil Engineer Corps with a data 
model from which to work in order to move forward with this type of project using their 
choice of developer. The prototype will also provide a conceptual starting point for the 
development of a final product. The community will be able to build on the concepts 
delivered in this prototype and change them as they see fit to meet the needs at the time 
of implementation. 
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II. PROJECT DEFINITION 


A. GENERAL 

A key element to a successful information technology project is a clear definition 
of the need for the project, the major areas of functionality for the project, and the users 
of the system to be delivered by the project. These elements become key in developing 
the requirements for the project. It is essential that any project meet the requirements for 
which it was intended. It is critical to deliver the requirements, but scope creep must be 
avoided. Proper definition of the project and adequate requirements analysis are effective 
strategies for accomplishing the project goals without allowing scope creep. This chapter 
deals with the clear definition of the project, while the next chapter will elaborate greatly 
on project requirements. 

B. PROJECT NEED 

The Civil Engineer Corps could benefit greatly from a central location for 
accessing community specific information. Two specific points make this need ideally 
suited to an online solution: 

• Civil Engineer Corps officers are spread around the world. 

• The amount of information available to be shared is tremendous. 

Given these points, it is clear that a single web-based resource providing access to 
the vast amounts of information would be an invaluable asset. Additional information is 
needed regarding the information available for dissemination. The following paragraphs 
detail the specifics of infonnation available for delivery to the community. 

1. Personnel Information 

The Civil Engineer Corps detailing shop (Naval Personnel Command Code 4413) 
manages all personnel information for the CEC. This information includes the 
management of all personnel in addition to the tracking of all command and billet 
information. This infonnation is maintained in a legacy database system at Naval 
Personnel Command (NAVPERSCOM). This information was discovered during a site 
visit in 2001. The system is an old hierarchical database model, which is accessed by 
multiple legacy applications for managing navy Personnel. This system is nearly 
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impossible to interface on a real-time basis. For the purposes of this project, the goal is 
to provide members of the community with online real-time access to billet and personnel 
information. This will be accomplished with a separate system, which will maintain the 
data necessary to provide the information needed by the community. A concurrent 
research project is developing a method for sharing data between the legacy system and a 
modern relational database. For the purpose of the portal prototype, the data model 
developed will be similar to and created in conjunction with the other research project. 
The NAVPERSCOM system does not maintain any personal member information such 
as home address, spouse information, phone numbers, and other information, which is not 
directly related to the member’s command. This additional functionality will be added to 
the capabilities of this system. 

2. Professional Resources 

Professional resources are another critical area of need for online information 
delivery. The community is diversified in background, qualifications, and job 
descriptions. There are three major areas of focus for professional development as a 
Civil Engineer Corps officer: Contract Management, Public Works Management, and 
Seabee Combat Warfare. Contract Management positions focus on the management and 
oversight of facilities construction and repair projects. Within this career field, there is a 
specific training path towards becoming an acquisition professional. The information 
associated with this training path is available in various locations. Public Works 
Management billets exist in order to maintain existing shore facilities. Standard training 
and manuals are available in order to assist members in becoming proficient in this field. 
The final area of focus for CEC officers is Seabee Combat Warfare. These billets are the 
only operational units to which members of the Corps are typically assigned. Warfare 
Qualification is a critical milestone during tours in Seabee battalions. Manuals and other 
general infonnation are available in order to prepare members for their service in a 
Seabee battalion. 

In addition to these specific areas of professional development, there are also the 
areas of Naval Officer Development and general Career Development. Resources are 
available to assist young officers in the planning and directing of their careers both as 

Naval Officers and as members of the Civil Engineer Corps. 
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3. Community Items of Interest 

In addition to the previously mentioned personnel and billet information, the Civil 
Engineer Corps regularly disseminates items of interest to all members of the community. 
These items are delivered in biweekly updates, which include news updates, awards to 
members, and orders releases. This information is currently distributed using e-mail with 
a link to a web document. 

C. GENERAL FUCNTIONALITY 

Given the general description of information resources available, basic areas of 
system functionality can be outlined. The development of this portal prototype will focus 
on providing functionality in the following areas: 

• Personnel information delivery and update capability. 

• Professional infonnation resources delivery. 

• Community items of interest submission and delivery. 

1. Personnel Information 

Personnel information is currently maintained by NAVPERSCOM code 4413. 
Billet and personnel information has traditionally been delivered in a print media once a 
year. This infonnation was limited to specific information related to members of the 
Civil Engineers Corps and their current billet infonnation. As this was an annually 
printed document, it was out of date soon after its printing and release to the community. 
Recently, this information has become available online in a searchable format; however, 
the search capabilities are limited, and update capability is not available. This web portal 
will give access to personnel and billet information as well as personal contact 
information at the discretion of the member. The portal will also give users access to the 
system in order to allow them to update their personal information. The goal will be to 
provide extensive search capabilities, including various types of personnel and billet 
searches. 

2. Professional Information 

The purpose of this portal is not to duplicate existing information. Rather, the 
goal is making existing information readily available. Professional infonnation is the 
most important area where this goal must be kept in mind. There are vast resources 
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available to deliver the professional development information needed by members of the 
Civil Engineer Corps. In order to make use of these extensive resources, members must 
be able to locate the information that they need. This portal will provide a jumping point 
to information resources available in other locations on the World Wide Web or intranets 
of various commands. Information will only be made accessible directly from this portal 
when no information is currently available in an online format for members of the 
community. 

3. Community Items of Interest 

Community interest items are currently delivered via e-mail to members of the 
CEC. This method of delivery was recently switched from a print-and-mail method, 
which had been used for several years, to an e-mail providing a link to a web document 
( http://www.navfac.navv.mil/pao-graphics/CECBiweekly020607.htm ). Typical items of interest 
delivered to the community include news updates, award presentations, and orders 
releases. Other information is periodically delivered including promotion selections and 
other general community information as it arises. This project will make this information 
available on a continuing basis. Information will be delivered based on the current date 
and the date of the item of interest. Users will have access to the system in order to 
submit new items for delivery to the community via the portal. 

4. Database Capability 

The database to support this web portal concept is an essential part of the 
development. MS Access will be used to develop a relational database that will be easily 
accessible from the web development environment using an ODBC connection. The 
database development will include the creation of all tables and their relationships. In 
addition, Access will be used for the Database Management System (DBMS). This 
functionality will provide quick, easy access to the information and will not be dependent 
on a connection to the web. This capability will be useful in the early stages of 
development when populating the database with data in order to test web developments. 
The Access DBMS will also be usable for users of the system after development, and that 
fact will be kept in mind during the creation of the data access forms. 
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D. USER IDENTIFICATION 


This project is limited in scope, as it is meant to be a proof-of-concept prototype 
demonstrating the viability of such a concept for the entire community. Because of this 
fact, the variety of users having access to the system will be limited. All users will be 
treated the same for access to the portal. The user experience will not be customized 
based on who the user is; rather, the users will be defined for the purpose of this project 
as a Civil Engineer Corps officer needing access to all of the above described information 
and capabilities. An advanced section will be available for the administration of some 
portions of the database. This will be the only distinction in users. The administration 
section will require different credentials in order to gain access. Figure 2 shows an 
interaction diagram between users and the elements of the system. 



Figure 2. System Interaction Diagram 

E. FEAS ABILITY 

Based on the need and general functionality defined above, this project is viable 
for completion. The limited functionality of the prototype keeps the project simple 
enough to be completed in a reasonable time but capable enough to demonstrate the 
applicability of such a concept for use by the community. 

There will be no additional cost associated with the development of this 
prototype. Hardware, including a workstation and a server, has been provided by the 
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Naval Postgraduate School for use during the thesis development. All software needed 
for development has been provided by the school, and there will be no labor cost 
associated with development because the manpower will be provided by student research 
time. 

As mentioned in Chapter 1, this project is beneficial to both the Navy and the 
Civil Engineer Corps. The knowledge gained through the completion of this project will 
add to the collective capabilities of the Civil Engineer Corps. This will be beneficial 
during the upcoming development of an enterprise-level portal for use by all members of 
Naval Facilities Engineering Command including military, civilian, and contractor 
personnel. 
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III. PROJECT REQUIREMENTS & DEFINITION 


A. DEVELOPMENT PLAN 

Rapid Application Development is used in this project for providing a phased 
development process for the Civil Engineer Corps community portal. In order to 
properly take advantage of this methodology, the project must be broken down into 
segments. The segments can be developed independently. The breakdown of this 
development will partially reflect the core functional areas of the project but will not 
follow them exactly. There are three main areas of information delivery required for the 
portal: personnel information, professional information, and community items of interest. 
The project will be broken into five main modules for development purposes. The three 
main areas of information delivery will all represent a development phase. Two 
additional phases will be added to the list. The first phase is the development of the 
supporting database for the portal. The second phase is the creation of the portal home 
page, which is a culmination of information from each of the functional areas. Each 
phase will consist of requirements analysis and design. The development will progress in 
the following order with a majority of the requirements analysis being done in the first 
two phases. 

• Phase 1 - Relational database development 

• Phase 2 - Home page and interface development 

• Phase 3 - Personnel information delivery 

• Phase 4 - Professional information delivery 

• Phase 5 - Community items of interest delivery 

Two design approaches are available for the design of this project A top-down 
approach involves starting with high-level strategic goals and working with these goals to 
develop a framework for the end product. A bottom-up approach is used in situation 
where a concept already exists for the end user system. This portal will be developed 
using a bottom-up approach. A general idea of what is to be provided to users of the 
portal already exists. This approach will allow for the derivation of design specifics from 
end level user requirements. (Kroenke, 2000, pp. 41-42) 
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B. 


GENERAL SITE PLAN 


In order to grasp an overall view of the project scope, a general site plan is 
provided to establish a guide for development. This general site plan can be seen in 
Figure 3 and is representative of the layout of the web portal to be developed. 



Figure 3. General Site Plan 
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This plan is derived from the general requirements set forth in the definition 
portion of this report. The plan does not include details of the specific number of pages 
on the site or any detail related to how those pages will interact. During Phases two 
through five, a detailed site plan will be developed based on the progression of the portal 
development. The general site plan details the core areas of functionality, a general plan 
for interaction between modules, and a representation of the project development phases. 
C. DEVELOPMENT TOOLS 

Web development tools have expanded greatly in their capabilities in recent years. 
Web pages, which could only be produced by an expert code writer just a few years ago, 
can now be created with simple point-and-click tools. Major offerings in the web 
development software arena include Macromedia Dreamweaver, Macromedia Ultradev, 
Microsoft .Net, Microsoft FrontPage, Adobe GoLive, Hotdog, and other lesser-known 
development tools. These same companies also offer other software in the arena of 
desktop publishing and photo editing, which can aid in the development of web graphics 
and other content. Some of these newer packages even provide the capability to write 
HTML code for graphics and actions created within the software. 

In addition to the extensive list of web development and graphics editing 
software, there are also numerous portal development packages available for the 
integrated design and deployment of large enterprise-level portals. This list of tools 
includes BEA WebLogic, Microsoft SharePoint, IBM WebSphere, Oracle 9iAS, and 
Sybase Enterprise Portal. These tools are focused on enterprise-level application 
delivery. The definition of a portal in the business arena is migrating towards 
collaborative interactive sites with a focus on accessing enterprise applications. This 
project is focused on a more traditional information delivery model of a portal. The 
development is small in scale; therefore, portal development products will not be used for 
the creation of this prototype. 

Based on previous experience Macromedia Dreamweaver, Ultradev 4 has proven 
to be an invaluable development tool in the creation of web pages and web-accessible 
database applications. This software will be used for the development of this portal. In 
addition, other software will be used for creation of the web content. Adobe Photoshop 6 
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and Macromedia Fireworks 4 are excellent resources for web graphic content 
development. Microsoft Visio 2002 will be used for the development of the entity 
relationship diagram and the site plan diagrams. Visio provides industry standard 
charting capabilities and interaction with web pages and databases. Visio was primarily 
chosen for this research work because of its high-level of compatibility with other 
products in the Microsoft suite. Its modeling capabilities are sufficient for this small 
project. There is only one additional capability that would be utilized on a project of this 
size - the ability to create a database directly from the model. Microsoft Access 2002 
will be used for the development of the relational database that will be used to support the 
portal. Microsoft Access provides robust database capability for small applications. 

D. GENERAL REQUIREMENTS 

The final desired deliverables become a starting point for the identification of 
requirements, when using a bottom-up approach. Using the necessary deliverables as a 
point of reference for the derivation of requirements ensures that the system will be built 
from the bottom up with the end user requirements at the core. Initial requirements 
analysis will be focused on identifying all the functional requirements of the portal 
identified by development phase. Table 1 identifies these requirements. Each 
requirement will be discussed in detail in the appropriate development phase, and 
additional requirements will be identified in later phases of the project as necessary. 
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Phase 1 - Relational database development 

Store data in an easy-to-manage relational database 

Provide a normalized data model based on the informtion needs of the portal 
Provide database management capabilities 
Phase 2 - Web portal home page and interface development 
Allow quick member search by last name 
Display missing e-mail address count 
Allow quick submission of missing e-mails 
Allow quick access to personal information updates 
Provide user friendly main interface 
Provide a common access menu structure 
Display recent community news 
Display recent community orders releases 
Display recent community award presentations 
Allow user login and session tracking 
Phase 3 - Personnel information delivery tools development 
Allow activity searches 
Provide detailed activity search results 
Allow member searches 
Provide detailed member profile search results 
Allow billet searches 

Phase 4 - Professional information delivery tools development 

Provide links to acquisition professional information 
Provide links to public works management information 
Provide links to Seabee combat warfare information 
Provide li nk s to general CEC career development information 

Phase 5 - Community items of interest information delivery tools 
development 

Deliver news 

Deliver award presentations 
Deliver orders releases 


Table 1. Project Requirements 
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E. PHASE 1 - RELATIONAL DATABASE DEVELOPMENT 

This phase, although not the primary focus of this project, is critical to the success 
of the prototype. The supporting database for any system can make infonnation delivery 
easy or impossible depending on the design of the database. 

1. Existing Data 

The focus of this project is not to create a fully populated database. The goal is to 
create an ideal relational model for the support of the portal. Much of the data needed to 
support this information delivery tool is not available in a database format. Specifically, 
professional information and community items of interest are not maintained in a 
database. In fact, the list of professional information is not even compiled. The li nk s are 
scattered over numerous sites across the World Wide Web. The final category of 
information to be stored is personnel infonnation. This data is maintained by Naval 
Personnel Command Code 4413. As mentioned previously, this information is 
maintained in a legacy database system. The data is not stored in a relational model and 
is unavailable for any type of link to the system. That being said, the data can be 
extracted in a comma separated value text file, but again, the data is not relational and is 
difficult to manipulate. 

Another thesis research project is underway currently to study the method by 
which the data can be linked or imported to a stand-alone system for use by the staff at 
NAVPERSCOM. Some data will be migrated from this system for functionality testing 
of the community portal, but a complete and accurate migration is beyond the scope of 
this thesis. This effort will be discussed in more detail in the implementation chapter. 
The database portion of this project will focus on the development of an efficient data 
model that meets the data requirements of the web portal not an existing database. This 
eliminates many of the many difficulties associated with database migration and/or 
population. 

2. Data Model Selection 

A data model type must be selected in order to meet the requirements of the 
project. Data models most commonly used in modern systems include hierarchical, 
object-oriented, and relational. Hierarchical is an older fonn of database used in many 
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older mainframe-terminal configurations. Object-oriented is the newest of these three 
options, but is complicated and often difficult to work with in creating a simple user- 
maintained database. (Date, 1990) Relational data models are commonly used in 
database implementations today. Relational models provide efficient storage of data in 
an easy to understand format. In a relational model, information is stored in entities, 
which are tables of “related” data. Information in different entities is related according to 
proper relationships. This method of data storage follows a logical pattern of 
organization, minimizes duplicated data, and eliminates certain processing errors 
generated by data stored in other ways. (Kroenke, 2000, pp. 17-18) The relational 
concept will be used for the development of this project. 

3. Requirements Analysis 

The requirements specifically related to the database development portion of this 
project are limited in quantity; however, the development of an efficient, easy-to-manage 
database is critical to the success of the portal concept. The requirements for this phase 
are simply stated as store data in an easy-to-manage database, provide a data model based 
on the information needs of the portal and provide database management capabilities. 

The information identified as data requirements is derived from two primary 
sources. The first is the print version of the Pi Civil Engineer Corps directory. This 
document is a guide for identifying the information required for proper tracking of 
community personnel information. Two sample pages from this document are included 
in Appendix A. The second source for identifying possible data to be stored is the Civil 
Engineer Corps Bi-weekly newsletter. A copy of the June 7th issue is included in 
Appendix B. Other information identified as data requirements comes from the 
developer’s knowledge of the community and the requirements for the web portal. 

In addition to the development of the data model and the Access database, 
database management must be included. For this project, the form creation capability of 
MS Access will be utilized. A Database Management system is necessary in order to 
provide access to and maintain the data. Additional database management will be 
provided to the end user through the web interface, and this will be discussed later in this 
chapter. 
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4. 


Database Schema 


The exact details of a database are explained in detail using the schema. The 
schema includes the entities, attributes, domains, and the business rules for the database. 
The schema is a design for the database. (Kroenke, 2000, pg. 30) Based on the specific 
database requirements and the overall core functionality of the system, a database schema 
model can be developed. In order to begin development of the data model, a 
brainstonning session is necessary to identify entities to store in the database. Figure 4 
shows the results of this session. 


Figure 4. Brainstorming Session Results 

The goal of the brainstorming session is to develop a list that will be refined and 
become the list of entities for the data model. The Entity Relationship Diagram can be 
developed based on a refined list. Based on the results of the brainstonning session and 
further consideration of data to be stored, Table 2 provides a list of entities that have been 
identified as primary for the data model. This list does not include intersection tables or 
lookup tables. These will be discussed in detail in the E-R Diagram section. 
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MEMBER PHONE 

BILLET ADDRESS 

ACTIVITY EMAIL 

ACTIVITYPHONE AWARDS 

QUALIFICATION NEWS 

PCODE LINKS 


Table 2. Primary Entity List 
a. E-R Diagram Creation 

The primary information to be stored in the database is personnel 
information. This includes information related to members, activities, and billets. 
Additional information included in the model is related to the submission of news 
updates, awards, and links to items of interest for the community. 

The simplified Entity Relationship Diagram is shown in Figure 5. It 
shows the relationship between all of the primary entities for this model. The detailed E- 
R Diagram with all attributes defined will follow. The logic for the Simple E-R Diagram 
is as follows. 
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The MEMBER entity represents a member of the Civil Engineer Corps. 
Members have addresses, phone numbers, and email address. Each member can have 
from zero to many of each. ADDRESS, PHONE, and EMAIL are the entities that 
represent this data. All addresses, phone numbers, and email addresses must be 
associated with a member, but a member does not have to have any of the above. Each 
member can have many Pcodes and qualifications represented by the PCODE and 
QUALIFICATION entities. There are many qualifications and pcodes. Each member 
can have from zero to many of each. Pcodes and qualifications need not have a member. 

Members are assigned to billets represented by the BILLET entity. Each 
member must be assigned to a billet, but a billet does not have to have a member. A 
member can be assigned to many billets during his or her career. Billets are associated 
with an activity represented by the ACTIVITY entity. An activity can have many billets, 
but a billet can only be associated with one activity. An activity is not required to have a 
billet, but a billet must be associated with an activity. Each activity can have from zero 
to many phone numbers stored in ACTIVITY PHONE. A billet can have one pcode as 
represented by the PCODE entity, but this is not required. A pcode does not have to be 
associated with a billet. Each billet can have a primary and a secondary qualification 
requirement. This information is stored in the QUALIFICATION entity. A billet is not 
required to have any qualifications, and qualification does not have to be associated with 
a billet. 

Members can submit community news updates, which are stored in the 
NEWS entity. A news update must be associated with the member who submitted it, but 
a member does not have to have submitted any news updates. Award announcements can 
be submitted for members of the community and are stored in the AWARDS entity. 
Members can receive from zero to many awards, and an award has to be associated with 
a member. Links to professional items of interest are to be stored in the LINKS entity, 
but this information is not associated directly with any other entity. 

Appendix C provides the detailed database schema in tabular format. The 
tables include all of the entities with their attributes and allowable values (domains). The 
tables indicate PK and FK relationships, which have been identified as unique, non-data 
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carrying integers in each entity. The information provided in the appendix is very 
comprehensive; however, the infonnation is best presented in a graphical format. Figure 
6 is the detailed entity-relationship diagram. It displays all of the infonnation from the 
simple E-R Diagram, but also includes the attributes for each entity, the intersection 
tables necessary for many-to-many relationships, and the lookup tables. 
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b. Business Rules 

The final element of the database schema is the business rules for the 
database. In this model, most of the data is constrained by the model itself therefore 
limiting the number of business rules necessary. Uniformity of data input is the primary 
requirement that is to be controlled by a business rule. In order to accomplish this in 
certain data fields, lookup tables are to be created. Entities will be created for the 
following information: designator, rank, type of address, type of phone number, type of 
e-mail address, category of web link, category of billet, state, sex, suffix, and race. These 
entities will be used as lookup tables (shown in Figure 7) in order to control values 
entered for specific values in other entities. 



Figure 7. Lookup Tables 

Each of the entities will be prefaced with “lookup” for ease of 
identification. Usernames will be controlled by a business rule for this portal. All 
usernames will be constrained to first initial, middle initial, and last name. As an 
example, Neil Christopher Rader would have “ncrader” as a username. This business 
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rule will not be enforced by the system. The input of usernames will be controlled by the 
database manager when inputting new users into the system. Duplicate values must be 
avoided in order to successfully management portal login accounts, which will be 
discussed in detail later. 

c. Normalization 

The goal in creating this relational model was to create an efficient 
database that eliminated data duplication wherever possible. In order to do this the 
database needs to be nonnalized to the maximum extent possible. Normalization is the 
process by which modification anomalies are eliminated from the database. The goal is 
to obtain Domain Key/Normal Form (DK/NF for the entire database. This is the highest 
level of normalization and will prevent all modification anomalies. “A relation is in 
DK/NF if every constraint on the relation is a logical consequence of the definition of 
keys and domains.” In order to make this definition more clear a breakdown of the three 
primary definitions in this statement are provided below. 

A constraint is defined as any rule governing the static values of an 
attribute. A key is a unique identifier for record in a table. The domain for an attribute is 
defined as the meaning of the attribute and the physical list of values it can have. In 
simpler tenns “...a relation is in DK/NF if enforcing key and domain restrictions causes 
all of the constraints to be met.” (Kroenke, 2000, pg. 126) This model was successfully 
normalized to a high degree; however, two specific issues were not dealt with. 

The first and most important of these is the relationship between billets 
and activities. In reality this relationship should be able to be represented using a many- 
to-many relationship. A set of data could be defined such that a finite list of billets could 
occur at numerous activities. Instead, the relationship is represented as a one-to-many 
relationship with one activity having many billets. The reason for this denonnalized state 
is the data available for the population of the database. A single job description might 
occur at two different locations, but its description in the NAVPERSCOM system might 
be different from one activity to the next. For an example, a public works officer billet 
will be considered. Each activity that has a public works officer will have a separate 
billet listed in the legacy system. One location may call this billet the public works 
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officer, another may simply list it as PWO, and still another may simply list it as the 
facilities director. This created a problem with data migration; therefore, this relationship 
was not normalized. 

The second issue is related to the use of the designator lookup table. The 
database was created and the project was well underway, when this information was 
identified as something that had the potential to change. The data is stored in the 
MEMBER and BILLET entities and merely looked up from the lookupDESIGNATOR 
table. If the information for a designator were to change data updates would be required 
to both the MEMBER and BILLET tables. The proper implementation for this data 
would be to relate members and billets to designators using a foreign key in these tables. 
The implementation would be similar to the relationship between billets and Pcodes. In 
fact, the data in the pcode table would soon be required to go through this very update 
because navy pcodes were changed recently. 

5. Database Creation 

With the conceptual design of the database complete, the Microsoft Access 
database can be created. Microsoft Visio was used as the tool for creation of the E-R 
diagram. The I-CASE tools mentioned earlier could have been beneficial in this primary 
area. More advance integrated software tools have the ability to take an entity 
relationship diagram and automatically create the database using the schema. 
Unfortunately, Visio does not have this capability. For this project, the Microsoft Access 
database was created manually in order to duplicate the database schema. Fortunately, 
Visio does have the capability to refresh a conceptual data model drawing by connecting 
to the database. This capability can be used to refresh the E-R diagram when any future 
changes are made to the database. With all tables and relationships created in MS 
Access, the database can be populated with a limited sample of data for demonstration 
purposes. 

6. Database Population 

The goal of this project is not to populate a fully accurate database; consequently, 
a simple data set will be created from existing data in order to demonstrate the 
capabilities of the system. Two flat files from the mainframe system at NAVPERSCOM 
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were used to populate approximately 1300 members, 450 activities, 1200 billets, and 
1100 sets of orders. This data set is not complete and is not up to date with all current 
member assignments, but the data is sufficient for prototype testing. The data chosen for 
migration was selected for ease of integration. Additional information was manually 
input into the system including addresses, phone numbers, e-mail address, and activity 
phone numbers. Member qualifications and pcodes were also migrated from the test files 
provided by NAVPERSCOM. Finally, a select group of awards and news stories were 
input from recent CEC bi-weekly newsletters, in addition to links to several sites with 
professional information for CEC officers. 

7. Database Management 

A database is useless if the information in it cannot be maintained in an intuitive 
user-friendly manner. Microsoft Access was chosen as the DBMS for this prototype 
project. Given this fact, the form creation capability of Access was selected as an 
interface for the database manager. Forms will be created to give the administrator 
access to add, edit, or delete all records in the database using the GUI interface. 

8. Form Creation 

In order to accomplish the goal of providing add, edit, and delete capability for all 
information in the database, several forms will need to be created. In addition, a central 
switchboard form will be created to grant access to each of the individual forms. The 
following is a list of all fonns to be created, and Figure 8 is a graphical representation of 
how they interact with one another. 

• Main Switchboard 

• Infonnation Resources Switchboard 

• Community Member Management 

• Shore Activity Management 

• Shore Billet Management 

• Member Orders Management 

• Web Link Management 

• Award Submission Management 

• News Submission Management 
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Figure 8. Form Interaction Diagram 


These forms are created using automated capabilities in Microsoft Access and 
then customized for more logical and meaningful arrangement of data. The main 
switchboard is shown in Figure 9, and the Community Member Management form is 
shown in Figure 10 as an example of a typical management form. All other forms are 
shown in Appendix D. The forms provide access to all information in the database and 
implement the primary business rule, which is use of the lookup tables mentioned earlier. 
The forms limit the choices in these fields tc only those availab'e in the associated 'ookup 
table. Figure 11 shows an example of this capability. 
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Figure 9. Main Switchboard 



Figure 10. Community Member Management 
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Figure 11. Lookup Table Example 

7. Database Testing 

The final step in the database phase of the project is the testing phase. Both the 
data model and the data management forms require testing. In order to accomplish this 
task, several additional records were put into the database using the management forms 
created in the previous section. During the input of these records, various minor changes 
to database field properties and form properties were identified and corrected. The result 
is a working system that allows access to all data, maintains rules of data integrity 
required by the E-R diagram, and properly implements the primary business rule required 
for this development. Several selected users were allowed access to the system in order 
to confirm its capabilities. 

F. PHASE 2 - HOME PAGE AND INTERFACE DEVELOPMENT 

This phase is the development of the of the primary access point for users of the 
portal. The development includes work on the home page for the portal and the 
considerations required in creating the entire site. It is the hub of the portal and is 
essential to success of the prototype. 
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1 . 


Server Model Selection 


In order to begin work on the creation of a database-driven website, a web server 
model must be selected. Dreamweaver, Ultradev 4 allows for the choice of three 
different models: Active Server Page (ASP), Java Server Page (JSP), and ColdFusion 
Markup Language (CFML). The server model specifies by what means the web pages 
will interact with the database server. Each of these models is similar in functionality in 
that they all deliver html code to the end user desktop. 

• ColdFusion was created by Allaire and is now owned by Macromedia. 
ColdFusion boasts its just-in-time compiler, which renders the CFML into 
the pages that are served. The CFML code encompasses a combination 
HTML and XML code. (searchDatabase.com, 2002) ColdFusion also 
boasts a very high level of interoperability between platforms and 
browsers. (Brooks-Bilson, 2001, pp. 1-5) 

• JSP, as the name implies, delivers dynamic content using java applets. A 
Java Server Page calls a Java program that is executed by the web server 
and then sent to the user. (searchSolaris.com, 2002) 

• An Active Server Page is a regular HTML page that contains one or more 
scripts to be processed by the server. ASP is a feature of Microsoft 
Internet Infonnation Server (IIS); however, since the scripts are 
interpreted on the server side, an ASP page can be delivered to almost any 
browser. The scripting language used can be either JavaScript of 
VBScript. 

It is also possible to run scripts on the client side, but this is not recommended 
because it can cause problems with browser interoperability. (searchWin2000.com, 
2002) Each of these tools provides access to essentially any standard database 
connection. 

ASP is to be used as the server model based on the developer’s knowledge of the 
model, the availability of a Windows 2000 Advanced Server with IIS 5.0, and the 
capability to perform server-side scripting with HTML code delivered to the desktop. 
JavaScript will be used for the scripting language. Although the user is more familiar 
with VBScript, there are more resources available for custom JavaScript expertise on the 
web. The following section gives a brief overview of the ASP model. 
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2. Active Server Page Model 

Since ASP has been chosen as the server model for this development, a brief 
description of the mechanics behind its operation is provided here. Figure 12 gives a 
graphical representation of the client server relationship involved in the model. 



Figure 12. ASP Server Model 

There are six Active Server objects. The Request object and the Response are of 
primary concern. The request object deals with requests from the client sent to the site or 
application most likely submitted from an HTML form. The Response object deals with 
the server response to the client browser. The Application and Session objects manage 
information about the application currently running. This unique instance of the 
application is called a session. 

The ObjectContext object is used for setting timeout properties for scripts and 
converting text into HTML or URLs. The server object is self-explanatory, but the 
CreateObject method of the Server object is of great importance. This method in 
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conjunction with the ActiveX Data Object (ADO) allows the ability to create, move, 
alter, or delete records in the database. This functionality is key to the success of a data- 
driven web page. (Kauffman, 1999, pp. 12-13) 

3. Requirements Analysis 

A review of the requirements previously identified for this portion of the project 
is necessary. They were defined as: 

• Allow quick member search by last name 

• Display missing e-mail address count 

• Allow quick submission of missing e-mails 

• Allow quick access to personal infonnation updates 

• Provide user friendly main interface 

• Provide a common access menu structure 

• Display recent community news 

• Display recent community orders releases 

• Display recent community award presentations 

• Allow user login and session tracking 

Based on this list and the success of the data model creation, the web application 
can be created to meet the prescribed requirements. One additional requirement not 
previously identified is the need for site accessibility. DoD mandates in Section 508 that 
all sponsored sites be accessible to everyone. (Section 508, 2002) 

4. Database Integration and Connection 

The first need for the creation of a data-driven web application is the connection 
to the database. This process has been streamlined and is now an integrated part of 
Microsoft operating systems. Open Database Connectivity (ODBC) is the method that 
will be used for this connection. ODBC allows for connection to essentially any standard 
database including SQL Server, Oracle, Access, and others. Dreamweaver automatically 
recognizes these connections and sets them up for use in newly created ASP pages. 

For connectivity to the database for use on the web, two primary methods can be 
used. Both of these methods involve the use of the Structure Query Language (SQL) for 
requesting and submitting data to and from the database. SQL is the standard for 
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information interchange between computers. It works on essentially any relational 
database, and runs on almost any computer or operating system. This again supports the 
goal of interoperability. SQL is a data access language that uses, SELECT, INPUT, 
DELETE, and UPDATE commands to manipulate the database. In addition other 
statements like WHERE and GROUP BY clauses can be used to specify criteria for the 
data manipulations. A detailed explanation of every aspect of the Structured Query 
Language is beyond the scope of this document, but a sample SQL statement and its 
explanation are shown below. In addition, Database Proccessing by David Kroenke is 
recommended as an excellent introductory text for the subject. 

SELECT DisplayDate, NewsID, Title, News 

FROM NEWS 

WHERE (((Month( [displaydate]))=Month(Date()))) 

ORDER BY DisplayDate DESC 

This statement requests the display date, ID, title, and story (News) from the table 
NEWS for all news stories where the display month in the record is the same as the 
current month, and then sorts the data from most recent display date to oldest display 
date. This will provide all news stories marked for display in the current month and 
display them with the newest story on top. 

The first method by which dynamic web pages can gain access to data through the 
development environment in Dreamweaver is directly through recordsets. A recordset is 
the set of data that a specific ASP uses. Each ASP page can make use of multiple 
recordsets if needed. Using this method, the developer directly connects to the database 
and writes the SQL statement directly into the recordset criteria. 

The second method of data access using the combination of Dreamweaver and 
MS Access is to develop the SQL queries in the Access database. The process is similar 
to the first method. However, by creating the queries in the database instead of 
Dreamweaver, the developer has direct access to the data that will be used by the ASP 
page without the use of the web development enviromnent. This practice is also 
beneficial in that it provides easy manipulation and editing of these queries, if they 
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should change at any time. This method of database query will be used for this project 
because of the maintainability that it provides. 

5. Login, Users, and Session Variables 

As was seen in the creation of the database earlier in this chapter, login 
usernames, passwords, and user levels will be stored for all members of the community. 
Using this method gives the website the capability of restricting access to members who 
are listed in the database and the ability to customize content for the current user. The 
login page can be seen in Figure 13. 



Prototype Development by LT Chris Rader CEC, U&N 

Site Developed at Pad of Master's Thesis Research 


Figure 13. Portal Login Page 
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The user level field, although populated in the database, will not be used for this 
development. Due to time constraints and the availability of the MS Access front end for 
the database, the administrator portion of the web portal will not be created at this time. 
This variable would have given the additional capability of granting access to 
administration pages only to those who had an administrator user level. 

Session variables are the means by which the ASP server model tracks the user 
while connected to the site. The username and password are stored in a session variable 
and carried by the server throughout the user’s active navigation of the portal. If a user 
logs out of the portal, closes his or her browser, or is inactive in the site for more than the 
session timeout period, the session variables are dropped. The session variables are 
initially stored after a successful login authenticated to the approved list of users in the 
database. A session variable can then be pulled to uniquely identify the current user to a 
database recordset. The use of this functionality will be demonstrated in the Member 
Record Updates section. 

6. Web Template Creation 

Through the creation of numerous websites, the developer has discovered that the 
use of web templates is highly desirable for the creation of sites larger than a few pages. 
A web template is used in the development environment as a starting point for the 
creation of new pages. Essentially, it gives all the pages the same look and functionality. 
In addition is provides the capability to update multiple pages at once in the future simply 
by changing the template. The template will address the issue of providing a common 
menu structure throughout the site. 

a. Format and Style 

An initial requirement for the portal is a user-friendly interface for the 
portal. User friendly is a vague term, but primarily incorporates two specific issues: ease 
of navigation and an aesthetically pleasing site. Three simple points can be used when 
developing a site contrast, readability, and accessibility. With these points in mind, a 
successful user interface should be attainable. 

Contrast refers to the proper use of colors for delivery of information and 
site creation. This goal is accomplished by using colors that complement each other 
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without being hard to distinguish. The easiest example of this is not to use a dark color 
on a dark color background (i.e. dark blue does not stand out on a black background. 
Figure 14 shows an example of good contrast next to a bad example. The color scheme 
for this project was chosen using the Civil Engineer Corps logo and The Fighting Seabee. 
The resulting color pallet is shown in Figure 15. 


Good Example 


Bad Example 


Figure 14. Web Contrast Example 



Figure 15. CEC Portal Palette 

Readability has a two-fold criterion. The first of these is to ensure the size 
and font selected for text to be displayed on the site is easy for users to see and read. The 
second half of the criteria deals with the delivery of information in an efficient manner. 
Users should not have to scroll anymore than necessary, and vertical scrolling is typically 
more desirable than horizontal scrolling. Several things go into the attainment of this 
goal including font selection, page layout, monitor size, and resolution. For this project, 
a standard web font set in Dreamweaver will be used. The font set includes Arial, 
Helvetica, and San-Serif. These fonts are simple and easy to read and are available on 
most systems in their standard configuration. The font set uses the first font if available 
on the system, or it works through the list until it finds one of the fonts for use on the site. 
The fonts are similar. This ensures that most users will see the page as the developer 
intended. Page layout is critical to the success of this goal. If a page is too graphic 
intensive, it will not have room for text that needs to be delivered. If the page has a lot of 
“white space,” the content will not fill up the page, and it will look void of information. 

Concerning monitor size and screen resolution, these vary greatly from location to 
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location. No one size can be counted on for all users, but it has been established, through 
conversations with numerous end users, that 1024 x 768 is a safe resolution to design for 
in most modern systems. There will be exceptions in both directions. Some users will 
have to scroll to see all content, and others will have too much “white space” on their 
page. This can be avoided by developing the site in two or three sizes, detecting the 
client resolution when the user accesses the site, and directing them to the appropriate site 
developed for their resolution. This is very intensive and will not be done for this 
prototype creation. 

Accessibility is also important to the successful design of a website. 
Again, there are two aspects to this criterion. The first is providing common user access 
to all infonnation on the site in an easy to locate fonnat. These issues will be addressed 
in the following section. The second is accessibility for disabled persons as required by 
Section 508. This issue will also be addressed in a follow-on section. 

b. Menus 

The common menu structure of the site is critical to providing users with a 
positive experience when visiting a site. The menu system is the core of the web 
template to be created for the site. By using a common menu throughout the portal, users 
can quickly identify and find their way around the site. The menu items to be used for 
this project are Home, News, Awards, Orders, Links, and Searches. These links give 
access to all of the resources on the site from all pages in the site. Appendix E shows the 
detailed site plan and how the menu structure works within the site for navigation. 

c. Section 508 Requirements 

“Section 508 requires that Federal agencies' electronic and information 
technology is accessible to people with disabilities.” (Section 508, 2002) In light of these 
requirements, research was completed to identify a list of requirements mandated by this 
regulation. Appendix F provides a quick list identified by the web center @ NIEHS 
(National Institute of Environmental Health Sciences). The template for this portal was 
created with these requirements in mind. Most of the requirements have been met, 
including one of the most obvious, which is the identification of graphical objects using 
the HTML ALT tag. This tag displays a pop-up text box for all graphical elements on the 


44 



page. In addition, all information li nk s presented using color were duplicated using text 
indication such as underlining. 

A detailed analysis of the site would be required to ensure that all 
requirements were met. This investment of time is unnecessary at this point because this 
is strictly a prototype development. 

7. Home Page Functionality 

The primary function of the homepage is to act as a central point for the entire 
portal. In addition, the most recent news, awards, and orders releases will be displayed. 
The page is designed with the menu system on the right, a central infonnation delivery 
section in the center, and quick access to information discussed in the next three sections. 
Figure 16 is a screen capture of the home page. 

The News and Awards sections list the two most current records. The orders 
section shows the most recent 20 sets of orders released. All other news, awards, and 
orders are provided in Phase III, IV, & V. Additional functionality of the home page 
includes identification of the member currently logged into the system. 
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Civil Engineer Corp« 


fgffli!Ma formation Delivery Portal 





Awards 
Orders 


Links 


| Search es 

TT 

T' \ 


J 


Current News 


Current Awards 


Home | 
News l 


TEST OF NEW CIVIL ENGINEER CORP 
PORTAL 

THE NEW CIVIL ENGINEER CORP INFORMATION 
DELIVERY PORTAL PROTOTYPE IS COMPLETE. 
WELCOME TO THE SITE. FEEL FREE TO EXPLORE AND 
ENJOY THE RESOURCE. SUBMIT COMMENT, 
CONCERNS, OR SUGGESTIONS TO LT CHRIS RADER AT 
NCRADER@NPS.NAVY.MIL. 

...more news 


NAVY & MARINE CORPS COMMENDATION 
MEDAL 

MERITORIOUS SERVICE WHILE SERVING AS 
FACILITIES MANAGEMENT/ENVIRONMENTAL OFFICER 
NAVAL SUBMARINE BASE, KINGS BAY, GEORGIA 
FROM APRIL 1998 TO AUGUST 2000. LIEUTENANT 
JUNIOR GRADE RADER'S EXCEPTIONAL 
PERFORMANCE RESULTED IN UNPRECEDENTED 
SUCCESS AS THE NAVAL INSTALLATION RECEIVED 
THE FY98 AND FY99 SECRETARY OF THE NAVY 
ENVIRONMENTAL AWARDS, AND THE 1999 STATE OF 
GEORGIA CHAMBER OF COMMERCE ENVIRONMENTAL 
LEADERSHIP AWARD. HE ORCHESTRATED AN IN- 
HOUSE BASE OPERATING SERVICES CONTRACTOR 
AND SELF-HELP RESOURCES TO REDUCE REPAIR 
PARTS MAINTENANCE DOLLARS AGAINST THE NEEDS 
OF A 1.3 BILLION DOLLAR INFRASTRUCTURE. WHILE 
ADMINISTERING A 15 MILLION DOLLAR FACILITIES 
MANAGEMENT BUDGET, HE LED THE DIVISION 
THROUGH A REVITALIZATION PERIOD WHICH 
RESULTED IN INCREASED EFFICIENCY AND MORALE. 
LIEUTENANT JUNIOR GRADE RADER'S EXCEPTIONAL 
PROFESSIONAL ABILITY, PERSONAL INITIATIVE, AND 
LOYAL DEVOTION TO DUTY REFLECTED GREAT CREDIT 
UPON HIMSELF AND WERE IN KEEPING WITH THE 
HIGHEST TRADITIONS OF THE UNITED STATES NAVAL 
SERVICE. 

..more awards 


Current Orders 


LT NEIL RADER to COMNAVFACENGCOMHQ WASH DC as FACPLN & PGM/ASST CIO 
LTJG NATHAN WILLIAMS to NPS STUDENTS MONTEREY CAas STUDENT 
LT MANUEL HERNANDEZ to NPS STUDENTS MONTEREY CAas STUDENT 
LT NEIL RADER to NPS STUDENTS MONTEREY CAas STUDENT 

LT WHITLEY ROBINSON to WHITE HOUSE M/O WASH DC as FAC CONST/SVC/SPECIAL PROGRAMS OFF-09F 



There are currently 1312 members 
with no e-mail address in the 
database 



Figure 16. Portal Home Page 


8. Quick Member Search 

One of the most useful functions provided by this portal is the quick location of 
addresses, phone numbers, and e-mail addresses of other community members. With this 
in mind, a quick member search was added to the home page. Members can search using 
any portion of a person’s last name. Upon submission of the request, the user is 
presented with a list of members meeting the search criteria. An example of the results 
page is shown in Figure 17. From the list of members, the user can choose to see the 
detailed record of the member. The detailed record contains all addresses, phone 
numbers, and e-mail addresses that the member has listed in the system. This page is 
shown in Figure 18. 
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Member Search Results 


Rank 

Name 

Year 

Group 

Desig. 

Current Activity 

Detailed 

Record 

CAPT 

KING, DANIEL P 

1980 

5100 

COMNAVFACENGCOMHQ WASH DC 

...GO 

LCDR 

KING, DOUGLAS W 

1983 

5105 

PWC WASHINGTON DC 

...GO 

CAPT 

KING, ROBERT H 

1978 

5100 

CINCPAC PEARL HARBOR HI 

-GO 

LT 

KING, SCOTT R 

1995 

5100 


...GO 

CW02 

STONEKING, TERRANCE ALBIN 

1990 

7531 


-GO 


Records 1 to 5 of 5 

Figure 17. Member Search Results Page 

View LT NEIL RADER's Information 
Current Assignment 


STUDENT AT NPS STUDENTS MONTEREY CA 


E-Mail Addresses 


Phone 

Numbers 


Type 

Address 


Type 

Number 


WORK 

ncraderfiYiDS .na vv. mi 1 


HOME 

1-831-3944031 X 


HOME 

ncraderi&msn.com 


WORK 

1-831-6562911 X 


HOME 

ncraderfihotmail com 


MOBILE 

1-831-2772298 X 


OTHER 

ncraderfiilvcos.com 


DSN 

8782911 


Addresses 





Type 

Street 

City 

State 

Zip 

Country 

HOME 

220 TUNISIA ROAD 

SEASIDE 

CA 

93955 

UNITED STATES 

WORK 

1 UNIVERSITY CIRCLE 

MONTEREY 

CA 

93943 

UNITED STATES 


Figure 18. Member Detail Page 
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7. 


Missing E-mail Notification 


One of the primary methods of communication between CEC community 
managers and community members is using e-mail. Because of this, it is very important 
that all members maintain an active e-mail address in the system. The home page 
displays the current number of members who have no e-mail in the system. This count is 
provided by using a SQL COUNT statement to count members not contained in the 
EMAIL entity. Directly under the count is a link, which takes the member to a list of all 
members with no address in the system. From this second page, the member can choose 
to submit a link, if they are on the “guilty” list. 

8. Member Record Updates 

A final resource accessible directly from the home page is a link to the member 
update section of the site. After following this link, the member is presented with a 
member detail page of his or her own personal information. This page is similar to the 
member details page accessible from the quick search function, but with the addition of 
edit, add, and delete links. These differences in this page can be seen in Figure 19. 


View LT NEIL RADER's Member Record 

Current Assignment 

STUDENT AT NPS STUDENTS MONTEREY CA 


E-Mail Addresses 

...submit a new address 

Phone Numbers 


...submit a new number 

Type 

Address 

Edit/Delete 

Type 

Number 


Edit/Delete 

WORK 

ncrader@nps .navy, mi 1 

edit / delete 

HOME 

1-831-3944031 X 


edit / delete 

HOME 

ncrader@msn .co m 

edit / delete 

WORK 

1-831-6562911 X 


edit / delete 

HOME 

ncradengfiot mai 1 .co m 

edit / delete 

MOBILE 

1-831-2772298 X 


edit / delete 

OTHER 

ncrader@) ycos .co m 

edit / delete 

DSN 

8782911 


edit / delete 

Addresses 





.. submit a new address 

Type 

Street 

City 

State 

Zip 

Country 

Edit/Delete 

HOME 

220 TUNISIA ROAD 

SEASIDE 

CA 

93955 

UNITED STATES 

edit / delete 

WORK 

1 UNIVERSITY CIRCLE 

MONTEREY 

CA 

93943 

UNITED STATES 

edit / delete 


Figure 19. Member Update Page 

This section takes advantage of the session variables discussed earlier. When a 
member clicks the link to update member records, the site uses the current username to 
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identify the record to display and allow update access. In other words, when users click 
on this link, they will only see their own infonnation because they are identified by their 
login name. Sample add, edit, and delete web forms are provided for address 
information. These are included in Appendix G. The forms for phone numbers and e- 
mail addresses are similar. 

G. PHASE 3, 4, & 5 - INFORMATION DELIVERY CAPABILITES 

These phases are combined for documentation purposes because their scope is 
limited and some of the functionality has already been provided in the previous phase. 
The home page provides quick access to recent news, awards, and orders release. In 
addition, the home page provides access to simple member searches, and user record 
updates. Having provided these capabilities directly from the home page reduces the 
work required in these last 3 phases. 

1. Phase 3 - Personnel information delivery 

The requirements for this phase include: 

• Allow activity searches 

• Provide detailed activity search results 

• Allow member searches 

• Provide detailed member profile search results 

• Allow billet searches 

The member search capability and detailed member profile viewing have already 
been provided through the quick last name search for members on the home page. This 
capability, although very useful, is limited. The search by last name requires more 
infonnation than some users may have. A user may wish to search using multiple criteria 
values such as rank and year group. The idea is to provide as much capability as 
possible. Figure 20 shows the advanced member search portion of the searches page. 
The values included in the search capability are first name, last name, rank, designator, 
and year group. The member can enter all or none of these values to be part of the search 
string. The results for this search are displayed in the same format as the quick member 
search previously identified and displayed in Figure 18. 
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Member Search 


First Name 
Last Name 
Rank 
Designator 
Year Group 


ADM 

3 



51 GO 


] 


Search 


Figure 20. Advanced Member Search Web Form 

Activity searches are also a required capability for the portal. This capability has 
been added using the following method. A user chooses a CEC Region to search in using 
a provided list of options. This portion of the advanced searches page is also shown in 
Figure 21. This search is submitted and the user is presented with a list of all activities in 
that region. A results page is shown in Figure 22. The user can then select an activity 
from the list and will be provide with a detailed report for that activity consisting of the 
address, phone numbers, and all members currently assigned to billets at that command. 
A screen capture of the results for Naval Facilities Engineering Command is included in 
Figure 23. 


Activity Search 


Region 


Naval District Washington 



Search 

■- _ 


Figure 21. Activity Search Web Form 
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Activity Search Results for EFA SOUTHEAST 


Name 

UIC 

City 

State 

Country 

PWC JACKSONVILLE FL 

68931 

JACKSONVILLE 

FL 

UNITED STATES 

ENGFLDACT SOUTHEAST JACKSONVILLE F 

JL 44226 

JACKSONVILLE 

FL 

UNITED STATES 

NAS JACKSONVILLE FL 

00207 

JACKSONVILLE 

FL 

UNITED STATES 

NAVSPTEL BICMD JACKSONVILLE FL 

32264 

JACKSONVILLE 

FL 

UNITED STATES 

NAVHOSP JACKSONVILLE FL 

00232 

JACKSONVILLE 

FL 

UNITED STATES 

NAVAVNDEPOT JACKSONVILLE FL 

65886 

JACKSONVILLE 

FL 

UNITED STATES 

HLTHCARE SUPPO JACKSONVILLE FL 

68907 

JACKSONVILLE 

FL 

UNITED STATES 

COMNAVREG SE JACKSONVILLE FL 

09697 

JACKSONVILLE 

FL 

UNITED STATES 

CBU FOUR ONE ZERO JACKSONVILLE FL 

66671 

JACKSONVILLE 

FL 

UNITED STATES 

NAS MAYPORT FL 

68709 

MAYPORT 

FL 

UNITED STATES 

NAVSTA MAYPORT FL 

60201 

MAYPORT 

FL 

UNITED STATES 

CBU FOUR TWO ZERO MAYPORT FL 

55162 

MAYPORT 

FL 

UNITED STATES 

NAVSUBASE KINGS BAY GA 

42237 

KINGS BAY 

GA 

UNITED STATES 

EFA SE CONT OFC KINGS BAY GA 

68248 

KINGS BAY 

GA 

UNITED STATES 

SWFLNT KNGS BAY GA 

68733 

KINGS BAY 

GA 

UNITED STATES 

CBU FOUR ONE TWO KINGS BAY GA 

66672 

KINGS BAY 

GA 

UNITED STATES 


Figure 22. Activity Search Results Page 
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Details for COMNAVFACENGCOMHQ WASH DC 


Address 10 Digit Code: 3361002000 

COMMANDER 

NAVAL FACILITIES ENGINEERING COMMAND 
1322 PATTERSON AVENUE SE, SUITE 1000 

WASHINGTON NAVY YARD DC 20374-5065 


Phone Numbers 
Type 

COMMERCIAL 

DSN 

FAX 


Billets 

BSC 

Description 

Rank 

Desig 

Currently Assigned 

01010 

P&P CHIEF/COMNAVFACENGCOM/CHCIVENG 

VADM 

5100 

RADM MICHAEL JOHNSON 

01040 

P&P CHIEF/VICE COMMANDER-09 

RDML 

5100 

RADM MICHAEL LOOSE 

03110 

FACPLN & PGM/DEP CDR ENG OPS 

RDML 

5100 

CAPT THOMAS BOOTHE 

04010 

FAC ENG/DIR NAVY PUB WORKS 

CAPT 

5100 

CAPT ARTHUR AYARS 

OHIO 

IG/ADDU TO 91180/47326 

CAPT 

5100 

CAPT RAYMOND MELLO 

01310 

PERS P&P CHIEF/DIR SEABEE READINESS 

CAPT 

5100 

CAPT JOHN SURASH 

02010 

FACPLN & PGM/DIR HOUSING 

CAPT 

5100 

CAPT THOMAS LIEDKE 

03130 

FACPLN & PGM/DIR CIO 

CAPT 

5100 

CAPT DANIEL KING 

05210 

FAC ENG/ASST CDR PGM COORD 

CAPT 

5100 

CAPT ANDREW BRUNHART 

05110 

FAC ENG/ASST CDR ENG RESRCES 

CAPT 

5100 

CAPT ERNEST KATZWINKEL 

04610 

FACPLN & PGM/DIR ENG OPS 

CAPT 

5100 

CDR JAMES JACKSON 

04010 

FAC ENG/DIR NAVY PUB WORKS 

CAPT 

5100 

CAPT WILLIAM BEARY 

01030 

EXEC ASST TO CDR-OOB 

CDR 

5100 

LCDR JOHN KORKA 

03190 

FACPLN & PGM/HD CSSO 

CDR 

5100 

CAPT PHILIP DALBY 

03220 

FACPLN & PGM/ASST DIR FLD OPS 

CDR 

5100 

CAPT THOMAS CALHOUN 

04630 

FACPLN & PGM/ASST DIR BUS ASSMT 

CDR 

5100 

CDR SUSAN GLOBOKAR 

05320 

FAC ENG/HD PW ADVOCACY 

CDR 

5100 

CDR CAMERON MANNING 

06070 

FAC ENG/DIR SEABEE DOCTRINE 

CDR 

5100 

LCDR DENNIS DUREN 

06070 

FAC ENG/DIR SEABEE DOCTRINE 

CDR 

5100 

CDR VINCENT RACANELLI 

06090 

FAC ENG/HD HSG PPV COORD OFF 

CDR 

5100 

CDR MICHAEL STOLL 

04320 

FACPLN & PGM/FLD OPS PGM OFF PAC 

LCDR 

5100 

LT ROLFE ASHWORTH 

06020 

FAC ENG/BRAC POLICY MGR 

LCDR 

5100 

LT TUAN NGUYEN 

02030 

FACPLN & PGM/FLD OPS PGM OFF LANT 

LCDR 

5100 

LCDR MICHAEL ARMES 

01651 

FAC RSCH/NCF PGM OFF/DVG GEN 

LCDR 

5100 

LT MICHAEL TEATES 

01630 

EXEC AS ST/C DR CONT ENG GRP 

LCDR 

5100 

LCDR KEVIN HUTSELL 


Figure 23. Activity Detail Page 


Number 

1-202-6859000 

3259000 

1-202-6851463 
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The final type of search required is a type of billet search capability. This 
functionality is intended to allow members to search for jobs in billets having their ra nk 
opening up during the month and year that they plan to rotate. To do this the user enters 
his or her ra nk chosen from a list of allowable values and enters the two digit month and 
four digit year in which they wish to search. The billet search portion of the searches 
page is shown in Figure 24. The results provide a list of billets and their associated 
activities. A Results page can be seen in Figure 25. 


Billet Search 


Rank 


ADM 



Date 


MM 


YYYY 


Search 

_ •' 


Figure 24. Billet Search Web Fonn 


Billet Search Results for 8-2003 


Description 

Activity 

Rank 

Desig 

Encumbent 

PW OPS/ASST DIR 

NAVSTA ROOSEVELT ROADS PR 

LT 

5100 

LT KEITH MIERTSCHIN 

CIV AFF/AOIC 

COMUSNAVSO CIVIC ACTION DET ROOSEVELT 
ROADS PR 

LT 

5100 

LCDR CARMELO MELENDEZ 

FAC CONST/SVC/AROICC 

ENGFLDACT MED SICILY ITALY 

LT 

5100 

LT LEAF BALLAST 

FAC CONST/S VC/ARO ICC 

ROICC MID-PACIFIC PEARL HARBOR HI 

LT 

5100 

LT DONALD BRUS 

FAC CONST/SVC/AROICC 

ROICC MID-PACIFIC PEARL HARBOR HI 

LT 

5100 

LT JAY MURPHY 

PWO (ASSISTANT) 

COMNAVACT LONDON UK 

LT 

5100 

LT RYAN TIBBETTS 

PW OPS/UTILITIES OPS OFF 

PWC PEARL HARBOR HI 

LT 

6530 

LT DAVID MCALISTER 

P WO/AD DU TO 17005/B8442 

NAVHOSP NAPLES ITALY 

LT 

5100 

LTJG NEIL WEST 


Figure 25. Billet Search Results Page 
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2. Phase 4 - Professional information delivery 

Professional information is limited to four categories four this prototype: Seabees, 
Public Works, Acquisitions, and General. Providing access to information in these 
categories is the driving requirement for this phase. This information is stored in the 
form of links to external sites. When a link is chosen, the user is taken to the external site 
to view the relevant information. This method was chosen for display of professional 
information because the task of maintaining all of the information at this one site is 
insurmountable and unnecessary. Since most of the resources needed by CEC officers 
for professional development are available somewhere on the web, the external li nk s 
were used. The links page is shown in Figure 26. 

Community Information Resources 

Seabee Links Acquisition Links 

CORRESPONDENCE COURSES 0 @ NAW ACQUISITION & BUSINESS 0 (Go) 


Public Works Links General Links 

CECOS 0 (Go) PROFESSIONAL REGISTRATION - INFO BY STATE 0 (Go | 


Figure 26. Information Resource Finks Page 

3. Phase 5 - Community items of interest delivery 

This final phase of development is provided for the development of the delivery 
pages for news, awards, and orders releases. As was previously identified in the home 
page development phase, these pieces of information are delivered in limited quantity on 
the home page. The detailed news, awards, and orders pages are used to grant access to 
all current information. The news and awards pages deliver information in sets of five. 
The orders page delivers information in sets of twenty. The user can navigate through the 
records using the recordset navigation menu at the bottom of these pages. Examples of 
each of these pages are provided in Appendix H. 
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H. COMPLETION, TESTING, AND TROUBLESHOOTING 

With all phases of development complete, final issues regarding completion of the 
site can be discussed. Essentially every detail of functionality provided by the site has 
been detailed in the previous sections. However, one item remains. Interlinking 
capability has been provided throughout the site. This capability allows a user to search 
for a member and then click on the activity that the member is stationed at and be 
directed to that activities detail page. The same is true for selecting member links on the 
activity pages. These direct the user to the member detail page. In addition, e-mail links 
on member detail pages are hyperlinks to call up the mailto function and call up the 
user’s default e-mail program with an e-mail to the selected member. 

Like rapid application development, testing and troubleshooting are an iterative 
process. Although testing was done throughout the duration of the development phases, a 
true test of the web portal and its interoperability with the database could not be 
performed until the database and portal were at a high percentage of completion. The 
remaining work involved in the development was an iterative use and troubleshoot 
method. The developer and other selected users accessed the portal and looked for errors, 
formatting issues, and other problems not yet identified. No major problems were found, 
but minor corrections to database web queries were made and some formatting 
adjustments were made to the site. 

This concludes the development portion of the project. A CD-ROM containing 
the database and the entire web application is included in Appendix I. Chapter 4 
addresses issues associated with the implementation of this or some similar concept for 
use by the community. 
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IV. PROJECT IMPLEMENTATION 


The prototype portal and supporting database are complete, and the issue of 
implementation must be discussed. This project was undertaken as a proof-of-concept to 
show that an information delivery tool such as a portal could be used to provide the Civil 
Engineer Corps with a wide variety of resources online. Providing a portal similar in 
concept to the one developed in this project would give members of the community 
access to the information it contains from any location with internet access. Portions of 
this project are usable as delivered in this prototype; however, others are not. In order to 
implement a similar working concept, several issues must be addressed. Currently, there 
is no plan to implement this system, but the intent of the developer is to provide a quality 
concept that will generate interest in pursuing a production model. In order for this to 
become a reality the items discussed in this chapter must first be considered. 

A. ARCHITECTURE 

The first issue to be addressed is the architecture to be used for hosting the 
database and the web portal. Two and three tier alternatives are to be considered. The 
current prototype utilizes a two tier architecture for the portal-database interaction, and 
single tier for the data management forms created in Access. The current implementation 
is not ideal for a working implementation. 

1. Two Tier 


A traditional two tier front end consists of a server and a client. Figure 27 shows 
a graphical representation of this model. 



Figure 27. Two Tier Architecture 
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The database is stored and managed on the server, which also hosts the website. 
The user interface or front end is provided to the client either through a desktop 
application and/or website. The client makes requests to the server. On the server side, a 
desktop application would interact directly with the DBMS. In addition, a web interface 
would connect directly to the web server which would communicate with the DBMS on 
the same server. 

2. Three Tier 

The three tier architecture model provides for the separation of user, application, 
and data. Figure 28 shows the interaction between the tiers in this model. 



Figure 28. Three Tier Architecture 

This structure is typically used in web-based applications. The user accesses the 
system through the client machine (i.e. a portal), the application or web server receives 
the requests and forwards them onto the database server, which in turns fulfills the 
request and returns the requested information to the client via the web server. This model 
is advantageous in that it separates the data from the application, which makes the 
information more secured. 

3. Selection 

The architecture used for the prototype is sufficient for that purpose, but an 
implemented solution would need to be more robust and allow for data separation. It is 
recommended that an end product would utilize a three tier architecture with all access to 
the data for users and managers provided through the web. The client would simply 
needed an internet browser such as Microsoft Internet Explorer, Netscape Navigator, or 
Mozilla in order to access the resources. The application server could be Microsoft 
Internet Infonnation Server, ColdFusion Server by Macromedia, or others. Finally, the 
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DBMS functionality should be provided by an industry standard product such as Oracle 
or SQL Server. This combination of products in the prescribed architecture would 
provide a robust capability with data integrity. 

B. DATA MIGRATION & MAINTENANCE 

There are several issues that must be addressed directly related to the data model 
and the existing data available for use. The project could not be successful without 
addressing these. 

1. Data Migration 

As was discussed in the database development section, the data model for this 
project was not entirely normalized. This was due to the format of the existing data. The 
data in its current form is not relational database friendly. The database in its prototype 
form would require manual interaction from the community detailer office. The dataset 
that has been entered into the functional prototype would need to be verified, updated, 
and completed. There is a substantial portion of the information missing. This is due to 
the difficulty of utilizing the existing legacy data. Also, a large portion of the personnel 
information is not currently stored in any database. The data populated in these entities 
was provided by supporters of the concept who are members of the community. Further 
discussion will follow on this subject in the conclusion chapter. 

2. Data Maintenance 

Many a wise person has said that a database is only as good as its data. There has 
never been a greater truth spoken. In order for a database application to be useful and 
productive, it must contain meaningful current data. This is a big hurdle for the proposed 
system. The information with respect to activity, billet, and orders is stored in a legacy 
system previously discussed. There is no current method of integrating the data. The 
system must be standalone. This creates additional work for the staff at 
NAVPERSCOM. The features of this site are not supported directly by the Navy at this 
time. However, the PI is a community supported item and will continue to be supported 
in some form. Member data supported by this prototype would be maintained by the 
user. In order to make this effort successful, users would have to be excited about the 
capabilities offered through this portal. If community was interested in the use of the 
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site, they would participate in properly maintaining their addresses, phone numbers, and 
e-mail addresses. 

C. SITE MIGRATION 

In order to make use of the system developed in this project, the portal would 
have to be migrated to a permanently supported site such as the NAVFAC Information 
Technology Center in Port Hueneme, California. Migration of a site from one server to 
another often involves a certain amount of troubleshooting. This fact was encountered 
when moving the site from the site which it was developed on to the system where it is 
currently hosted. Issues that often arise during migration include database connectivity 
problems, file permission issues, and web server configuration conflicts. Each of these 
problems was encountered during the migration to the SeabeeOne server that currently 
hosts the site. These problems are not insurmountable. Rather, they are things which 
should be considered if the portal was migrated to a production server. 

Since this portal will probably not be implemented in its current state, the 
migration issues are not critical. Any new developments based on the prototype could 
use the application server function of the Dreamweaver development environment to 
eliminate most of this problem. 

D. USER MANUAL AND TRAINING 

A user manual was not provided with this documentation because the project is 
simply a prototype and there are no immediate plans for implementation. If the system 
was utilized, a user manual and training would need to be provided, at a minimum to the 
community managers who would be maintaining the data. Proper use of the system 
facilitated by proper instruction ensures that the data will be kept in a proper manner. 
The portal has been created with simplicity in mind; therefore, little instruction should be 
required for members of the community who would be accessing the site. Also, most 
members of the community are familiar with the internet and the operation of typical sites 
found there. This site follows those same development guidelines and should be very 
familiar to users accessing the site. 
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E. OTHER ISSUES 

1. Contractor Support 

If a decision is made to proceed with this concept, a choice would have to be 
made regarding whether to use the prototype and enhance or create a new site from 
scratch. In a government environment, either of these options lend themselves to a 
contractor developed and supported site. Resources are available through the NAVFAC 
CIO office to support such an effort. A contractor could provide advanced data migration 
and web development capabilities, and future support for the application. 

2. NMCI 

In order for this project to proceed using the Dreamweaver development 
environment, a waiver would have to be granted since it is not currently on the list of 
approved software. Microsoft FrontPage is on the approved list; however, its capabilities 
are highly limited for web-based data applications. This issue could be moot if a 
contractor was used for development and support. 
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V. CONCLUSION 


A. LESSONS LEARNED 

Throughout the course of this project, a few specific items have been identified as 
things to avoid in future developments of similar projects. This section is not devoted to 
identification of every mistake made during the development. It simply exists to point 
out key changes in the process that would have streamlined the development. 

1. Data Modeling 

The creation of the schema is critical to the success of any project involving 
access to a database. Obtaining a properly nonnalized data model is often a process of 
trial and error, but it must be done to the largest extent possible to help prevent future 
data errors and duplication. The lesson learned in this area is to begin the creation of the 
data model with a very open mind. This is often difficult to do, but it can make the 
creation of the model much easier if it is accomplished. If the developer attempts to 
create the model but has preconceived ideas about the data involved, obvious 
relationships may be missed. 

As an example, the relationship between activities and billets is considered at this 
time. In the Civil Engineer Corps, activities have several billets associated with them. 
Several activities may have a Public Works Officer billet; however, the data from the 
NAVPERSCOM legacy system treats each of these Public Works Officer billets as a 
unique billet and might possibly have different short descriptions for the billet. In a 
proper model, this would be one billet at many activities. In other words, the relationship 
would be many-to-many. This fact was overlooked during the initial creation of the data 
model. This causes duplication of data and inefficiency in the design. In the end, this 
mistake was left in the design of the model for the prototype because it made population 
of the database substantially simpler. Without this allowance, the data would have 
needed to be manually scrubbed to find all billets, which were actually the same. This 
effort was more than allowed for in the development of this system. If a system of 
similar design were put into place, a decision would have to be made regarding whether 
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to continue to allow the model irregularity or to nonnalize this relationship and fix the 
data. 

2. Lookup Confusion 

During the initial creation of the database, it was decided to use lookup tables for 
control of the allowable values for several entity attributes such as types and categories. 
In the design of this portal, data for addresses, phone numbers, and e-mail addresses are 
to be utilized. The decision was made to use a lookup table for the allowable list of type 
values for these data records. Initially a single entity was created containing all possible 
types for each of these data types. Later, it was discovered that the use of this tables for 
lookup in forms, web pages, and other tables would be confusing. The reason for this 
was the availability of toll-free as a type of e-mail in drop-down menu lists and other 
similar confusing options. The correction for this problem was to create an independent 
lookup for each type of data: address, phone number, and e-mail address. A similar 
problem was discovered in the use of the category lookup for both billets and infonnation 
resource web links. Both of these problems were corrected in order to eliminate the 
confusion. 

3. Web Design 

Two valuable lessons were learned with respect to approaches to web design, 
especially regarding pages containing dynamic content. The first of these is related to the 
use of web templates for the creation of a site. A template can be a curse and a blessing. 
The convenience of a template is that it allows you to create multiple pages with identical 
content on some portion of the page. This is specifically useful for creating a common 
navigation or menu system for the site. 

The first primary lesson identified in this section is the importance of perfecting 
the template before the creation of additional pages. The reason for this is the need for 
template updates. If the template is changed after the creation of other pages, the 
development environment is able to update the additional pages that have been created 
based on the modified template. However, these updates are not always entirely 
successful. Specifically, the use of certain automated server behaviors and custom scripts 
may fail. These items sometimes prevent the proper update of the subsequent pages. 
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When this happens, the additional pages must be fixed one at a time. This problem was 
experienced late in the development of this prototype when the logout functionality was 
to be added to all pages throughout the site. The template was updated with a link and an 
automated logout script created by Dreamweaver UltraDev. The update to all pages in 
the site was successful, or so it seemed. Upon further inspection and testing of pages 
throughout the site, it was discovered that many pages had a script error caused by the 
logout addition. This error, if identified early in the development, could have been dealt 
with. In the end, this behavior was removed from every page except the homepage, 
which was not based on the template. Therefore, users must either close their browser or 
return to the homepage in order to properly logout of the site and clear their session 
variables. 

The second web design lesson learned is to plan a page thoroughly before 
attempting to build it. Sketch the page, think it over, re-sketch it, and repeat until there is 
a high level of comfort with the design of the page and the information to be delivered. If 
this is done, it will prevent the need to recreate the page from scratch several times in 
order to obtain the desired result. This method can be extended throughout the site by 
sharing page designs in the creation of future pages with similar data reporting 
requirements. This is similar to the use of the template but in greater detail. 

B. FUTURE WORK 

As this project comes to completion, it is clear that the concept has been proven, 
but it is not yet ready for use by the community. There are several reasons for this. This 
section provides specific areas that should be addressed in future work to make this 
prototype more suited for a production system. 

1. Data Standardization and Validation 

An effort was made, during the creation of the data model, to restrict the users 
input of data wherever possible. The use of lookup tables and controlled domains were 
the primary method by which this was accomplished. Most data that could be 
constrained was; however, there are a few other areas where this capability could be 
provided. Specifically, the use of a lookup table for the country code prefix for phone 
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numbers and the country name for addresses could be standardized. This list would have 
to manually generated or obtained from other source. 

The method by which to store phone numbers was a struggle for the developer. 
The existence of activities and billets in many other countries suggests that several 
different fonnats could be used. This issue could be evaluated further in order to identify 
a more consistent format for the storage of these numbers. 

Additionally a primary area in which functionality was not provided is data 
validation. The Microsoft Access database forms have built in validation. They will not 
allow a record to be created if a required value is null. Although the program provides 
messages to indicate which required fields were not populated, it would be beneficial to 
designate theses fields on the form so that the user would not receive an error message 
from the system. Web form validation was not provided due to time constraints. The 
concept is simple. The application server checks to see if all required values are entered 
before submitted the information to the database. If fields are left null, the client should 
identify to the user that certain fields must be completed. Web pages would also benefit 
from clear identification of required fields. Specific fonnats for data to be entered into 
web forms could also be indicated on the page. This would help prevent database 
corruption caused by incorrectly fonnatted data. 

2. Fine Tuning 

Both the Access database forms and the web pages could greatly benefit from 
additional “fine-tuning” before this system was made accessible for use by the entire 
community. All forms and pages should be scrubbed to ensure that data display fields 
and lookup menus are sized properly to view all data in the field. This is a simple task 
and was partly completed during the creation of this project, but not thoroughly tested 
with the data set populated. One specific area suggested for improvement of the web 
portal is the elimination of scrolling wherever possible. The site was designed for 1024 x 
768 resolution, which is available and used on many DoD computers. The development 
process was a learning experience for this project. The web template was created using 
certain sizes for HTML content tables. These tables often cause pages to show a scroll 
bar when there is no information stored off screen. The other cause for scrolling is the 
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delivery of too much dynamic content to a single formatted page. For example, the home 
page delivers the two newest awards and news stories along with the 20 newest sets of 
orders. This information typically causes the page to scroll because of the quantity of 
information delivered. This type of behavior could be evaluated throughout the site and 
eliminated where possible and desired. The elimination of all scrolling within the site 
makes the site much more usable for the fast-paced users that are typically accessing the 
web. Users want information quickly, and they do not want to be required to do a lot of 
“clicking” to get it. 

3. Web Functionality 

Additional functionality could be added to the portal in the form of award and 
news submissions, or additional interactive or drilldown-type search capabilities. The 
“items of interest” submissions were originally intended as part of this project but were 
eliminated due to time constraints. The system in its current state can only accept these 
submissions through the data management forms in Access. These submissions would be 
critical to the success of a production site. The variety of searches on members, 
activities, and billets is nearly endless. The community could be polled for additional 
capabilities that they would be interested in seeing added to the site. If the community 
were involved in future efforts such as these, it would most likely garner additional 
support for the concept and add to its chance of success. 

4. Database Integration 

The last area of future work is likely the most important. The issues associated 
with the current state of data in the NAVPERSCOM legacy system have been mentioned 
previously. In order to make this entire concept a reality, the maintenance of the data 
would need to be as simple as possible and require little interaction on the part of the 
detailing office staff. In order to make the concept viable, the detailing office would have 
to be willing to maintain the data. In order to prevent the duplication of data, an 
integration method between the legacy system and the portal database should be 
established. This could come in the fonn of a direct connection to the NAVPERSCOM 
system, but this option is highly unlikely. A realistic goal would be to create an import 
routine that would update this system using the ASCII text file output from the 

mainframe system. Another research project is currently underway to accomplish this 
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very task. The initial development of the data model for both of these projects was done 
simultaneously; however, additional changes are expected in model for the other research 
project. This research is not yet complete. When it is completed, it will meet one of the 
primary requirements for the progression of this portal to a working implementation. 
This portal research would have to be revisited upon completion of the data integration 
research in order to assess changes to the data model and evaluate its use with the 
existing portal web pages. 

C. FINAL THOUGHTS 

This project started with a grand vision in the mind of one student. The result is 
not the full-blown production model that was initially envisioned, but the research did 
address the primary question of what a prototype model for a Civil Engineer Corps 
Community portal could look like. A successful working prototype with database and 
website were created, and the concept was proven as a viable information delivery tool 
for use by the community. Portions of the portal could be implemented with little to no 
additional work. Other parts require additional work to implement successfully - some of 
which is ongoing. As stated in the beginning, the internet has become a powerful tool for 
providing information to almost anyone, anywhere. This project proves that this concept 
can be extended to this community to provide a wealth of information to a myriad of 
officers around the world. 
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APPENDIX A: PI SAMPLE PAGES 


PAGE IS REPRESENTATIVE OF FORMAT, BUT CONTAINS NO VALID DATA 


Civil Engineer Corps Active Duty Personnel 


Page 

Number 

Name 

Rank 

Year 

Group 

Activity Name 

PCode 

Designator 

34 

SALTER, JEFFREY MITCHEL 

LCDR 

1986 

NAVSUPPACT NEW 

1101P 

5100 

100 

SANDERS, SCOT T 

LT 

1992 

ENGFLDACT MED 

1101P 

5100 

16 

SASEK, DAVID JOHN 

LCDR 

1987 

COM THREE ONE NCR 

1101P 

5100 

36 

SCANLAN, STEVEN RAYMOND 

CDR 

1982 

CG MCB CAMP LEJEUNE 

1101P 

5100 

84 

SCHANZE, CHRISTOPHER NMN 

CAPT 

1978 

PACNAVFACENGCOM 

1101P 

5100 

59 

SCHILLING, LEONARD CARL 

LT 

1992 

NAVSUBASE KINGS BAY GA 

1101P 

5100 

83 

SCOTT, BRIAN MERRITT 

CDR 

1981 

ROICC MID-PACIFIC 

1101P 

5100 

23 

SHEEDY, WILLIAM MALCOLM 

LCDR 

1986 

NAF ATSUGI JAPAN 

1101P 

5100 

46 

SHOEMAKER, JERRY J 

LT 

1992 

CBC PORT HUENEME CA 

1101P 

5100 

5 

SNOW, RALPH GORDON 

CDR 

1983 

CINCPACFLT PEARL 

1101P 

5100 

92 

STILL, AARON MICHAEL 

LT 

1996 

NMCBFOUR 

1101P 

5100 

85 

STOLL, MICHAEL JOHN 

CDR 

1982 

COMNAVFACENGCOMHQ 

1101P 

5100 

60 

STRATMAN, ALLAN MARK 

LCDR 

1986 

NMCB THREE 

1101P 

5100 

61 

SURASH, JOHN E 

CAPT 

1976 

COMNAVFACENGCOMHQ 

1101P 

5100 

121 

SYKES, MARSHALL TROUTMAN 

LCDR 

1988 

FACILITIES PROGRAM 

1101P 

5100 
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PAGE IS REPRESENTATIVE OF FORMAT, BUT CONTAINS NO VALID DATA 


EFA SOUTHEAST LISTING 


Page 

Activity Name 

UIC 

Commercial Phone 

35 

PWC JACKSONVILLE FL 

68931 

(904) 589-0943 


ENGFLDACT SOUTHEAST JACKSONVILLE FL 

44226 

(904) 930-9398 


NAS JACKSONVILLE FL 

00207 

(904) 399-9388 

36 

NAVSPTEL BICMD JACKSONVILLE FL 

32264 

(904) 939-3990 


NAVHOSP JACKSONVILLE FL 

00232 

(904) 849-9487 


NAVAVNDEPOT JACKSONVILLE FL 

65886 

(904) 653-9489 


HLTHCARE SUPPO JACKSONVILLE FL 

68907 

(904) 849-4985 


COMNAVREG SE JACKSONVILLE FL 

09697 

(904) 859-9494 

37 

CBU FOUR ONE ZERO JACKSONVILLE FL 

66671 

(904) 843-4899 


NAS MAYPORT FL 

68709 

(904) 985-9585 


NAVSTA MAYPORT FL 

60201 

(904) 849-4994 

38 

CBU FOUR TWO ZERO MAYPORT FL 

55162 

(904) 445-9488 


NAVSUBASE KINGS BAY GA 

42237 

(912) 938-3948 


EFA SE CONT OFC KINGS BAY GA 

68248 

(912) 943-3933 


SWFLNT KNGS BAY GA 

68733 

(912) 343-4944 

39 

CBU FOUR ONE TWO KINGS BAY GA 

66672 

(912) 839-3930 
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APPENDIX B: CEC BIWEEKLY SAMPLE 


CEC Biweekly 07 June 2002 


Chief of Civil Engineers 

CEC Biweekly 

07 June 2002 



In This Issue 

I Y0.1 C.F t. Captain .Stall Bp.lfiiJinns 

MemmaiiJmii ul UmJeislantluiu Signed kit Hula Gunaliudiun 

2002 Lateral fransler Board 

Hems of Interest 

Awards 

Military Personnel Inluf inprfion 

Address Change Information 

(~!F f! Riuupnlcly Input Intrirmaf inn 

CPC Riui/nnkly Past Issiips 


FY03 CEC Captain Staff Selections 


NAVFAC 


Seabees 


NCTC 


U.S. Navy 


Detailer 


The following active duty Civil Engineer Corps officers have been selected for promotion to Selection Boards 

Captain ^ _ 


CDR Michael L Blount 
CDR David M Boone 
CDR David M Burnes 
CDR Francis P Castaldo 
CDR Mason Crum 
CDR David L Fleisch 
CDR Paul T Fuligm 
CDR Katherine L Gregory 
CDR April F Heinze 


CDR Hugh R Hemstreet 
CDR Kevin A Lindsey 
CDR Barry K Loveless 
CDR Gerald R Manley 
CDR Roger M Natsuhara 
CDR Michael J O'Connor 
CDR Eric S Odderstol 
CDR Robert P Walden 


The following active limited duty Civil Engineer Corps officer has been selected for 
promotion to Captain 


CECOS 


NFACT 


Perspective 


Professional 

Reading 


Recruiting 


Tricare 


CDR David C Phillips 


The following reserve Civil Engineer Corps officers have been selected for promotion to 
Captain 


CDR Kenneth C Alexander 
CDR Paula C Brown 
CDR Stephen E Elrod 
CDR Timothy W Hamberg 
CDR Larry A Hibner 
CDR Robert V Huffman 
CDR Robert H Kelly 
CDR Mark E Kistner 
CDR Herve M Kopciak 
CDR Donald E Kuellmer 
CDR Terrence M Mahoney 
CDR Robert S Meyer 


CDR Hans Probst Jr 
CDR Ricky V Richards 
CDR Gregory R Rismiller 
CDR Charles E Silva 
CDR Joel E Sinn 
CDR Theodore E Spear 
CDR David L Sullivan 
CDR Douglas P Taylor 
CDR Michael G Ward 
CDR William R Whittenberg 
CDR Terry L Wilkerson 
CDR James R Wood 
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CDR David K Mori CDR Timothy G Zakriski 

CDR Scott A Morris 
CDR Thomas P Newdome 

The following reserve limited duty Civil Engineer Corps officer has been selected for 
promotion to Captain 

CDR James T Conen 

tot* \<j Iw 


2002 Lateral Transfer Board 


Congratulations to the following officers who were recently selected for transfer to the Civil 
Engineer Corps 

LT Thomas M Bestalka, Chemical Engineering, NRD New York 

LT Daryl J Lotempio, Civil Engineenng, USS BRIDGE 

LT Wallace M Mattos. Civil Engineenng. NAVSEA 

LT Daniel M Schormann, Mechanical Engineenng, NRD San Antonio 

LT Andrew J Sullivan. Civil Engineenng, JCS 

LT Robert G Tetreault, Ocean Engineering, EWTG Lant 

LTJG Mansa K Barrie, Mechanical Engineenng, NPTU Charleston 

LTJG Angelo D Fontanazza. Systems Engineenng. USS GEORGE WASFIINGTON 

LTJG Sarah L Franson. Civil Engineering, NAVSAFECEN 

LTJG Wesley W Hamill, Civil Engineering, USS MORISON 

LTJG Bnan J Longbottom. Civil Engineering, USS RM DAVIS 

LTJG Roberto Maldonado, Mechanical Engineering, USS ARCTIC 

LTJG Edward B Miller. Civil Engineering, PHIBRON EIGHT 

LTJG David B Noya, Mechanical Engineenng, CSRO San Diego 

LTJG Megan M Pagano. Engineering Science, USS HIGGINS 

LTJG Pablo F Sierra, Aerospace Engineenng, USS GONZALEZ 

ENS Jeffrey A Brelsford, Industrial Engineenng, USS HERON 

ENS Danny Cerezo. Architecture, USS ANTIETAM 

ENS Constance L Danner, Civil Engineering, USS SPRI JANCE 

ENS Matthew J Gaudet, Mechanical Engineering, USS JUNEAU 

Congratulations to the following Civil Engineer Corps who were selected for augmentation 
to the Regular Navy 


LT Jay A Bieszke 
LT Deanna S Carpenter 

LT Michael A Comstock 
LT Patnck T Connor 
LT Danny H Cruz 
LT James D Ekberg 
LT Lance M Flood 
LT Joshua J Gamez 
LT Cassie A Gorman 
LT Julie A Hrdlicka 


LT Ronald J Jenkins 
LT Jason G Kranz 
LT FTiillip M Lavallee 
LT Gerald C Lowe 
LT Thomas B McLemore 
LT Joseph C Pope 
LTJG Brian L Clapp 
LTJG Eric W Hahn 
LTJG Marc F Williams 


harit tfi trip 
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• For the first time, “Joint" J4 Engineers from the United States Joint Forces Command 
(USJFCOM) attended the Contingency Engineering Seminar at the Civil Engineer 
Corps Officers School (CECOS) in Port Hueneme, Calif The one-week class was 
designed to improve the effectiveness of those who may have to provide operational 
engineenng support in a Joint Task Force (JTF) environment It addressed the 
organization of |omt task forces, DoD and civilian engineering capability, |oint 
engineer functions, civil engineer support planning, facility acquisition management, 
host nation support, and capabilities of U S and international contingency 
organizations While hosted by CECOS, the course included not only instructors from 
CECOS, but also a host of visiting instructors from Navy, Manne Corps, Air Force, 
and Army They represented various commands such as U S Southern Command, 
Naval Facilities Engineering Command, 1st Marine Expeditionary Force and the 
National Emergency Preparedness Liaison Office 

• A ribbon cutting ceremony was held recently for a new wharf constructed in San 
Oiego Bay. Calif, to support the USS NIMITZ (CVN 68) which is scheduled to make 
San Diego its new home sometime this fall Besides the new wharf, a storage 
warehouse, equipment staging building, and a fleet recreation center was also built 
The 90-feet wide by 1,300 feet long wharf runs parallel with San Diego Bay, and 
connects to a recently completed pier where USS JOHN S STENNIS (CVN 74) is 
berthed SOUTHWESTDIV managed the contract for the project, which is valued at 
approximately $51 3 million 

hark In top 


Awards 


Defense Meritorious Service Medal 

LT Whitley H. Robinson, CEC, USN, March 1999 to Apnl 2002 As Officer in Charge, 

Special Programs Office, Metro F leld Office, Policy, Plans, and Requirements, White House 
Military Office, established working relationships with more than 16 government 
departments and agencies to create unity of effort for a critical, large-scale classified 
project Directed a project directed by the White House Chief of Staff, completing all actions 
in two weeks Led the renovation of a Presidential command center, accelerating the 
schedule by 85 percent while integrating complex and changing requirements levied by 
senior White House Staff 

Meritorious Service Medal 

CAPT Brian M Scott CEC, USN, June 1999 to May 2002 As ROICC. Pearl Harbor, 

Hawaii, executed a $778 million acquisition program throughout Hawaii, Johnston Atoll, and 
Wake Island Imfilemented innovative process improvements that resulted in enhanced 
acquisition planning and engineering integration and produced an annual savings of $7 9 
million Led the ROICC team in executing a myriad of technically complex and time-cntical 
projects, including the $18 million renovation of the Commander, Pacific Fleet Headquarters 
and a $32 million construction project to provide consolidated waterfront piers at Naval 
Station Pearl Harbor 

CDR Michael J. Stoll, CEC, USN, July 1998 to September 2001 As Public Works Officer, 

Naval Air Station Oceana, Virginia Beach, Va , consolidated three public works operations 
serving NAS Oceana. Fleet Combat Training Center Atlantic, and the Public Works Center, 

Virginia Beach site into a single team Improved the combined organization's efficiency and 
effectiveness and reduced overhead, resulting in an annual savings of more than $2 5 
million Orchestrated facilities preparations, including $100 million in construction required 
to meet the base realignment and dosure-directed receipt of 10 F/A-18 squadrons and 
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Military Personnel Information 


CDR Kevin R Slates to MCB Camp Lejeurte. N C 
LCDR Bradley S Hancock to CNET, Pensacola. Fla 

LCDR Michael P Oestereicher to EFA NORTHEAST Contracts Office, Brunswick, Maine 
LT Karl R Cupp to (DUINS) Colorado University, Boulder, Colo 
LT Sarah L Deutermann to LANTDIV Contracts Office. Sewells Point. Va 
LT Joseph L Greeson to 22ND NCR, Gulfport, Miss 
LT Chnstopher J Lee to NAS Sigonella, Italy 

LT Matthew P Lesser to EFA NORTHEAST Contracts Office, Earle. N J 
LT Thomas J Lyons to SOLTTHWESTDIV, San Diego, Calif 
LT Joshua B Malkin to (DUINS) University of Maryland, College Park, Md 
LT Jeffrey E McCoy to NMCB FOUR, Port Hueneme, Calif 
LT James G Meyer to OICC MED Contracts Office, Sigonella, Italy 
LT CristopherP Neishto (DUINS) Georgia Tech Atlanta, Ga 
LT Stephen H Pitman to PACDIV DET MIDPAC, Pearl Harbor, Hawaii 
LT Russell C Rang to LANTDIV. Norfolk, Va 
LT Mikhael H Ser to 22ND NCR, Gulfport, Miss 

LT William A Sprauer Jr to (DUINS) University ofTexas, Houston, Texas 

LT Neil E West to (DUINS) Colorado University, Boulder, Colo 

LT Ra Yoeun to (DUINS) University of Maryland, College Park, Md 

LTJG Jason A Edelberg to EFA CHES, Washington, D C 

LTJG Dustin Kwok to NAVACTS United Kingdom, London 

LTJG Shawn P Pope to NAVBASE Ventura County, Point Mugu. Calif 

ENS Eiwln A Rico to NMCB ONE, Gulfport, Miss 

ENS Preston D Taylor to NMCB 40, Port Hueneme, Calif 

ENS Enk P Ulmen to 22ND NCR, Gulfport, Miss 

back to fop 


CEC Biweekly Address Changes 

Active duty, reserve, and retired e-mail addresses may be updated online. For active 
duty Civil Engineer Corps officers, visit www na^/fac naw.mil/cec-list/adive cfrn For reserve 
Civil Engineer Corps officers, visit www navfar, navy mil/cec lisf/re.serve r.fm Retired CEC 
officers can now provide their e-mail addresses to receive the electronic CEC Biweekly by 
visiting www navfacnavy mil/cec-list/refire r.fm All CEC officers should keep their e -mail 
addresses current within the system as these e-mail addresses will also be used to 
disseminate other official information 

For active duty officer address changes, please contact Dennis Potter at DSN 882-4031. 
commercial (901) 874-4031, or send an e ^nail to p4413sffipersnet.navy.mil For reserve 
officer address changes, contact John Anderson at (202) 685-9014 or e -mail at 
andetscuiifffiiiaylac.iiayy.nul 
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If you have information you would like to submit to the CEC Biweekly, mall to the address 
below or send an e-mail to Drema McCoy at mnnnydnugnavfan navy mil You may also call 
her at DSN 325-9008, commercial (202) 685-9008 or fax at (202) 685-1484 If you have 
award information, please fax or mail a copy of the signed citation 

CEC Biweekly 

Naval Facilities Engineenng Command 
1322 Patterson Ave SE, Suite 1000 
Washington Navy Yard, D C 20374 -5065 

back la tap 
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APPENDIX C: DATABASE SCHEMA 


Entity Name 

Description 

ACTIVITY 

This entity contains information related to commands to which Civil Engineer Corps officers are assigned. 

Field 


1 


Description 


Allowable 

Values 

Required 

ActivitylD 

y/ 


Uniquely identifies activity 

Integer 

Autonumber 

✓ 

Name 



Command name 

VarChar (75) 


✓ 

UIC 






✓ 

Claimancy 



Claimancy 




Region 



NAVFAC Region 

V arChar (25) 

Lookup Table 


Street 1 



1 st line of street address 

V arChar (50) 


✓ 

Street 2 



2nd line of street address 

V arChar (50) 



Street 3 



3rd line of street address 

V arChar (50) 



Street 4 



4th line of street address 

V arChar (50) 



City 



City 



✓ 

State 



State 

V arChar (2) 

Lookup Table 

✓ 

Zip 



Zip code 

V arChar (5) 


✓ 

ZipPlusFour 



Plus 4 zip code 

V arChar (4) 



Country 




V arChar (25) 



lODigitCode 




Plilul 











Entity Name 

Description 

ACTIVITY PHONE 

This entity contains phone number information for activities. 

Field 

Properties j 

n 


Description 

Type (length) 

Allowable 

Values 

Required 

A ctivityPhonelD 

✓ 


Uniquely identifies phone 
number 

Integer 

Autonumber 

✓ 

ActivitylD 


✓ 

F or eign key prop erty information provide d in foreign table 

✓ 

Type 



Type of number 

V arChar (15) 

Lookup Table 

y/ 

CountyCode 



Country code 

V arChar (5) 



Are aC ode 



Area Code 

V arChar (5) 



Number 



Phone Number 

V arChar (20) 


y/ 

Extension 



Extension 

V arChar (8) 











Entity Name 

Description 

MEMBER 

This entity contains information related to members of the Civil Engineer Corps. 

Field 

Properties | 

n 


Description 

Type (length) 

Allowable 

Values 

Required 

MemberlD 

v' 


,[□ j; ,i 1 1 ^ m f-ff 11 » 1 1.. 1 1 1 at. < j 

iByEH-fMA i. t 

Autonumber 

✓ 

FirstName 



First name 

V arChar (25) 


✓ 

MiddleName 



Middle initial 

V arChar (2) 



LastName 



Last name 

V arChar (25) 


^^1 

NickName 



Go-by name 

EESBESl 



Suffix 



Name suffix 

V arChar (5) 

Lookup Table 


SSN 






✓ 

Rank 



Rank 

V arChar (7) 

Lookup Table 

y/ 

Designator 



Designator 


Lookup Table 

y/ 

Race 



Race 

EE5233M 

Lookup Table 


Sex 



Sex 

EE3SBMI 

Lookup Table 


YearGroup 



YearGroup 


Lookup Table 

y/ 

Username 



Portal Username 

V arChar (20) 



Password 



Portal Password 

V arChar (20) 



UserLevel 



Portal User Access Level 

V arChar (15) 

Administrator 

User 


|- K .. - ~ - 'I 
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Entity Name 

Description 

ADDRESS 

This entity contains address information for members of the Civil Engineer Corps. 

Field 


n 


Description 

Type (length) 

Allowable 

Values 

Required 

AddressID 

✓ 


Uniquely identifies addresses 

Integer 

Autonumber 

✓ 

MemberlD 


V' 

Foreign key property information provided in foreign table 

S 

Type 



Type of address 

V aiChar (15) 

Lookup Table 

S 

Street 1 



1 st line of street address 

V aiChar (50) 


S 

Street 2 



2nd line of street address 

V aiChar (50) 



Street 3 



3rd line of street address 

V aiChar (50) 



Street 4 



4th line of street address 

V aiChar (50) 



City 



City 

V aiChar (25) 


S 

State 



State 

VarChar (2) 

Lookup Table 

S 

Zip 



Zip 

V aiChar (5) 


S 

ZipPlusFour 



Plus 4 zip code 

V aiChar (4) 



Country 



Country 

V aiChar (25) 











Entit> r Name 

Description 

PHONE 

This entity contains phone information for members of the Civil Engineer Corps. 

Field 


i 


Descrip tion 

Type (length) 

Allowable 

Values 

Required 

PhonelD 

✓ 


Uniquely identifies phone 
number 

Integer 

Autonumber 

✓ 

MemberlD 


✓ 

Foreign key property information provided in foreign table 

✓ 

Type 



Type of number 

V aiChar (15) 

Lookup Table 

✓ 

CountryCode 



Country code 

V aiChar (5) 



Are aC ode 



Area Code 

V aiChar (5) 



Number 



Phone Number 

EESaEul 



Extension 



Extension 

V aiChar (g) 











Entity Name 

Description 

EMAIL 

This entity contains e-mail addresses for members of the Civil Engineer Corps. 

Field 

Properties j 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

EMaillD 

S 


Uniquely identifies phone 
number 

Integer 

Autonumber 

✓ 

MemberlD 


✓ 

Foreign key property information provided in foreign table 

✓ 

Type 



Type of e-mail 


Lookup Table 

✓ 

i rrSafT »ll 
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Entity Name 

Description 

MEMBER BILLET 

This entity contains information necessary to relate community members to billets. 

Field 

Properties | 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

MemberlD 

v' 

✓ 

Foreign key property information provided in foreign table 

✓ 

BilletID 

v' 

✓ 

✓ 

ReportDate 



Report date 

Date/Time 

MM/DD/YYYY 

✓ 

PRD 



Project Rotation Date 

Date/Time 

MM/DD/YYYY 

✓ 

DisplayDate 



Date to display on portal 

Date/Time 

MM/DD/YYYY 

✓ 







mm 



Entity' Name 

Description 

MEMBER QUALIFICATION 

This entity contains information necessary to relate qualifications to members of the Civil Engineer Corps. 

Field 

Properties I 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 


MemberlD 

✓ 

✓ 

Foreign key property information provided in foreign table 


QualificationID 

✓ 

✓ 









i MMI 




Entity Name 

Description 

MEMBER PCODE 

This entity contains information necessary to relate pc odes to members of the Civil Engineer Corps. 

Field 

Properties 1 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

MemberlD 

✓ 

✓ 

Foreign key property information provided in foreign table 

✓ 

PCodelD 

✓ 

✓ 

✓ 





1 





Entity Name 

Description 

BILLET 

This entity contains information related to billets for members of the Civil Engineer Corps. 

Field 

Properties j 

I 


Description 

Type (length) 

Allowable 

Values 

Required 

BilletID 

✓ 


Uniquely identifies billet 

Long Ineger 

Autonumber 

S 

ActivitylD 


✓ 

Foreign key property information provided in foreign table 

S 

PCodelD 


✓ 


BSC 



Billet Sequence Code 

V arChar (10) 


v' 

Description 



Short name of billet 

V arChar (50) 


S 

Category 



Billet Category 

VaiChar (25) 

Lookup Table 

S 

Rank 



Rank required for billet 

V arChar (7) 

Lookup Table 


Designator 



Designator required for billet 

V aiChar (7) 

Lookup Table 


Active 



Indicates billet active/inactive 

Boolean 

Yes 

No 

S 

StartDate 



Start date for billet availability 

Date/Time 

MM/DD/YYYY 


EndDate 



End date for billet availability 

Date/Time 

MM/DD/YYYY 










Entity Name 

Description 

BILLET QUALIFICATION 

This entity contains information necessary to relate qualifications to billets. 

Field 

Properties | 

l 


Descrip tion 

Type (length) 

Allowable 

Values 

Required 

MemberlD 

✓ 

✓ 

Foreign key property information provided in foreign table 

✓ 

QualificationID 

✓ 

✓ 

✓ 

Status 



Indicates primary or seconday 
qualification code for billet 

V arChar (10) 

Primary 

Secondary 

✓ 
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Entity Name 

Description 

PCODE 

This entity contains pcode information for members and billets of the Civil Engineer Corps. 

Field 

Properties 1 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

PCodelD 

✓ 


Uniquely identifies a pcode 

Integer 

Autonumber 

✓ 

PC ode 



Professional Code 

VarChar (7) 


✓ 

Description 



Professional Code Description 

V arChar (5) 


✓ 










Entity Name 

Description 

QUALIFICATION 

This entity contains qualification information for members and billets of the the Civil Engineer Corps. 

Field 

Properties j 

PK 

FK 

Descrip tion 

Type (length) 

Allowable 

Values 

Required 

Qualification^ 

✓ 


Uniquely identifies a 
qualification 

Integer 

Autonumber 

✓ 

AQD 



Qualification Code 

VarChar (7) 


✓ 

Description 



Description of qualification 

VarChar (50) 


✓ 










Entity Name 

Description 

AWARDS 

This entity contains awards received by members of the Civil Engineer Corps. 

Field 

Properties 1 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

AwardID 

✓ 


Uniquely identifies award 

Integer 

Autonumber 

✓ 

MemberiD 


✓ 

F oreign key prop erty information provide d in foreign table 

✓ 

DisplayDate 



Portal display date 

Date/Time 

MM/DD/YY 

✓ 

Award 



Award name 

VarChar (50) 


✓ 

Description 



Detailed award description 

Memo 












Entity Name 

Description 

LINKS 

This entity contains links to professional information needed by members of the Civil Engineer Corps. 

Field 


i 


Description 

Type (length) 

Allowable 

Values 

Required 

LinkID 

✓ 


Uniquely identifies a link 

Integer 

Autonumber 

✓ 

Category 



Information category 

rPWWrTil 

Lookup Table 

✓ 

URL 



Worldwide Web URL 

Hyperlink 


✓ 










Entity' Name 

Description 

NEWS 

This entity contains news updates for Civil Engineer Corps community items of interest. 

Field 

Proper-ties j 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

NewsID 

✓ 


Uniquely identifies news 
update 

Integer 

Autonumber 

✓ 

MemberiD 


✓ 

Foreign key property information provided in foreign table 

✓ 

DisplayDate 



Portal diplay date 

Date/Time 

MM/DDAT 

✓ 

News 



News update 

Memo 


✓ 
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Entity Name 

Description 

lookupCATEGORY 

This entity contains lookup values for catergories of billets. 

Field 

Properties 1 

1 


Description 

Type (length) 

Allowable 

Values 

Required 

CategorylD 

✓ 


Uniquely identifies a category 

Integer 

Autonumber 

✓ 

Category 



Billet category 

VarChar (25) 

Seabee Combat Warfare 

A c quisition Profe s sional 

Public Works Management 

Staff 

General 

School 

✓ 









Entity Name 

Description 

lo okupC ATEGORYlink 

This entity contains lookup values for catergories of web links. 

Field 


B 


Description 

Type (length) 

Allowable 

Values 


CategorylD 

a 


Uniquely identifies a category 


Autonumber 

✓ 

Category 



Web links category 

V arChar (50) 

Seabees 

Acquisitions 

Public Works 

General 

✓ 























Entity Name 

Description 

lookupDESIGNATOR 

This entity contains lookup values for military designators. 

Field 

Properties 1 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

Designator ID 

v' 


Uniquely identifies a category 

Integer 

Autonumber 

✓ 

Designator 



Alphanumeric designator code 

V arChar (7) 

5100,5105,6530,6531, 

6532,7531,7535,7530, 

1110,1115,1120,1125, 

1165,1175,1310,1315, 

1320,1390, 1395 

✓ 

Description 



Description of the designator 

V arChar (100) 

ACTIVE DUTY CIVIL ENGINEER CORPS OFFICER 

ACTIVE DUTY RESERVE CIVIL ENGINEER CORPS OFFICER 
CIVIL ENGINEER CORPS LIMITED DUTY OFFICER (LDO) 
CIVIL ENGINEER CORPS LIMITED DUTY OFFICER (LDO) 
CIVIL ENGINEER CORPS LIMITED DUTY OFFICER (LDO) 
CIVIL ENGINEER CORPS CHIEF WARRANT OFFICER (CWO) 
CIVIL ENGINEER CORPS CHIEF WARRANT OFFICER (CWO) 
CIVIL ENGINEER CORPS CHIEF WARRANT OFFICER (CWO) 
SURFACE WARFARE QUALIFIED URL OFFICER 

SURFACE WARFARE QUALIFIED URL OFFICER 
SUBMARINE WARFARE QUALIFIED URL OFFICER 
SUBMARINE WARFARE QUALIFIED URL OFFICER 

URL OFFICER IN TRAINING FOR SURFACE WARFARE 
QUALIFICATION 

URL OFFICER IN TRAINING FOR SUBMARINE WARFARE 
QUALIFICATION 

URL OFFICER QUALIFIED AS A NAVAL AVIATOR 

URL OFFICER QUALIFIED AS A NAVAL AVIATOR 

URL OFFICER QUALIFIED AS A NAVAL FLIGHT OFFICER 
URL OFFICER IN TRAINING AS A NAVAL AVIATOR 

URL OFFICER IN TRAINING AS A NAVAL AVIATOR 

✓ 

Importance 



Used for sorting of designator 
by order of community 
importance 

Integer 


✓ 
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Entity Name 

Description 

lookupRACE 

This entity contains lookup values for race. 

Field 


1 


Description 

Type (length) 

Allowable 

Values 

Required 

RacelD 



Uniquely identifies a category 

Integer 

Autonumber 

✓ 

Race 



T ext de s cription of rac e 

VaiChar (7) 

White/Caucasian 

Black/African American 

Amercian Indian/Alaskan N ative 

Asian American/Pacific Islander 

Hisp anic/Latino/Latina 

Other 

Undeclared 

✓ 

ShortRace 



One letter code for race 

VaiChar (2) 

W, B, I, A, H, 0, X 

✓ 
















Entity- Name 

Description 

lookupRANK 

This entity contains lookup values for rank. 

Field 

Properties 1 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

RankID 

✓ 


Uniquely identifies a category 

Integer 

Autonumber 

✓ 

Rank 



Text description of rank 

VaiChar (7) 

ENS, LTJG, LT, 

LCDR, CDR, CAPT, 

RDML, RDMU, 

VADM, ADM, 

CWOl, CW02, 

CW03, CW04 

✓ 

Imporance 



Allows for sorting of rank by 
seniority 

Integer 


✓ 
















Entity Name 

Description 

lookupREGION 

This entity contains lookup values for region. 

Field 

Properties j 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

RegionID 

✓ 


Uniquely identifies a category 

Integer 

Autonumber 

✓ 

Region 



Civil Engine ering C orp 

Division 

VaiChar (30) 

N aval District Washington 

Atlantic Division 

EFA Mediterranean 

EFA Chesapeake 

EE A Northeast 

Southern Division 

EFA Southeast 

EFA Midwest 

Southwest Division 

EFA West 

EFA Northwest 

Pacific Division 
























Entity Name 

Description 

lookupSEX 

This entity contains lookup values for sex. 

Field 

Propeiiies j 

I 


Description 

Type (length) 

Allowable 

Values 

Required 

SexID 

✓ 


Uniquely identifies a category 


Autonumber 


Sex 



Biological identification from 
birth 

VaiChar (1) 

M 

F 

S 
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Entity Name 

Description 

lookupSTATE 

This entity contains lookup values for state. 

Field 

Properties 1 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

StatelD 

y/ 


Uniquely identifies a category 

Integer 

Autonumber 

S 

State 



State identification 

VaiChar (2) 

AK, AL> AR, AZ, CA, 

CO, CT, DC, DE, FL> 

GA, HI, IA, ID, IL, 

IN, KS, KY, LA, MA, 

MD, ME, MI, MN, MO, 

MS, MT, NC, ND, NE, 

NH, NJ, NM, NV, NY 

OH, OK, OR, PA, RI, 

SC, SD, TN, TX, UT, 

VA, VT, WA, WI, WV, 

WY, AW, AP, AA 

S 























Entity Name 

Description 

lookupSUFFIX 

This entity contains lookup values for type of suffix. 

Field 

Properties 1 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

SuffixID 

✓ 


Uniquely identifies a category 

Integer 

Autonumber 

✓ 

Suffix 



Suffix identification 

V aiChar (5) 

I 

II 

III 

IV 

JR 

SR 
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Entity Name 

Description 

lo okupT YPEaddre s s 

This entity contains lookup values for types of addresses. 

Field 

Properties j 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

TypelD 

✓ 


Uniquely identifies a category 

Integer 

Autonumber 

✓ 

Type 



Type of address 

VarChar(15) 

Work 

Work2 

Home 

Home2 

✓ 























Entity Name 

Description 

lo okupT YPEemail 

This entity contains lookup values for types of email addresses. 

Field 

Properties j 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

TypelD 

✓ 


Uniquely identifies a category 

Integer 

Autonumber 

✓ 

Type 



Type of e-mail address 

VarChar (15) 

Work 

Work2 

Home 

Home2 

Other 

✓ 























Entity Name 

Description 

lo okupT YPEphone 

This entity contains lookup values for types of phone numbers. 

Field 

Properties | 

PK 

FK 

Description 

Type (length) 

Allowable 

Values 

Required 

TypelD 

□ 


Uniquely identifies a category 


Autonumber 

✓ 

Type 



Type of phone number 

VarChar (15) 

Work 

Work2 

Toll Free 

DSN 

Fax 

Home 

Home2 

Mobile Pager 

Other 

Commercial 

✓ 
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APPENDIX D: MANAGEMENT TOOL SCREEN SHOTS 





Name 

[STUDENT - 


Activity 

|NPS STUDENTS MONTEREY CA 

UIC BSC Active (7 

[31*405 [99990 

Billet Start Date Billet End Date 

I I 

Billet Qualifications 

Qualification Description 

3 3i 


Designator: PCode 

| 31 [00S9T 3 

Rank 

31 | 3 

Category 

[SCHOOL 3J 


Status 

I 3 


Currently Assigned 


Rank 

FirstName 

LastName 

Report Date 

PRD 

|LT 

“31 | PHILLIP 

[CYR 

| VI/2001 

17/31/2002 

|LT 

“31 [BRIAN 

| WEINSTEIN 

[8/1 /2000 

[9/30/2002 

|LT 

“31 [NEIL 

| RADER 

|9/30/2000 

16/21/2002 

P 

3] | MANUEL 

|HERNANDE2 

1 9/1/2001 

|9/30/2003 

[ltjg 

33 | NATHAN 

|WILLIAMS 

[97172001 

19/30/2003 


Record: 14 | 4 1 1 1194 ► I H [►*! of 1266 
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Award 

|naw 8c marine corps commendation medal 

Description _ 

Meritorious service while serving as Facilities Management/Environmental Officer Naval Submarine 
Base, Kings Bay, Georgia from April 1998 to August 2000. Lieutenant Junior Grade Rader's 
exceptional performance resulted in unprecedented success as the Naval installation received the 
FY98 and FY99 Secretary of the Navy environmental awards, and the 1999 state of Georgia 
chamber of commerce environmental leadership award. He orchestrated an in-house base 
operating services contractor and self-help resources to reduce repair parts maintenance dollars 
against the needs of a 1.3 billion dollar infrastructure. While administering a 15 million dollar facilities 
management budget, he led the division through a revitalization period which resulted in increased 
efficiency and morale. Lieutenant Junior Grade Rader's exceptional professional ability, personal 
initiative, and loyal devotion to duty reflected great credit upon himself and were in keeping with the 
highest traditions of the United States Naval service. 


Recipient Display Date 

[RADER [NEIL [9 /I /2000 


Record; l< | i 1 1 u ► I H |Mf| of 11 




Q@M 

► 

Title 


|Date Set for Washington, D.C., NAVFAC/CEC/Seabee Anniversary Ball 


News 


The Washington, D.C., NAVFAC/CEC/Seabee Anniversary Ball will be held on 9 March at the Crystal 
Gateway Marriot in Arlington, Va. It will mark the 160th anniversary of the Naval Facilities Engineering 
Command, the 135th of the Civil Engineer Corps, and the 60th of the Seabees. As is tradition, 
NAVFAC HQ events will begin at 11:00 with the 28th annual Seabee Memorial Service at the Seabee 
Memorial in Arlington. 

During the ball, the Rear Admiral Lewis B. Combs and the Steelworker Second Class Robert B. 
Stethem awards will be presented to individuals who have made outstanding contributions to the 
legacy of the Seabees. To pay special recognition to the Seabees' 60th birthday, the Seabee 
veterans who helped pave our way to victory during World War II will be honored. 


Submitted By Display Date 

[RADER Tj [NEIL [G7T72002 

Record; H | < 1 1 5 ► I H l>*| of 18 
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APPENDIX E: DETAILED SITE PLAN 



Login Page 
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APPENDIX F: SECTION 508 SHORT LIST 


1. A text equivalent for every non-text element shall be provided (e.g., via "alt", 
"longdesc", or in element content). 

2. Equivalent alternatives for any multimedia presentation shall be synchronized 
with the presentation. 

3. Web pages shall be designed so that all information conveyed with color is also 
available without color, for example from context or markup. 

4. Documents shall be organized so they are readable without requiring an 
associated style sheet. 

5. Redundant text li nks shall be provided for each active region of a server-side 
image map. 

6. Client-side image maps shall be provided instead of server-side image maps 
except where the regions cannot be defined with an available geometric shape. 

7. Row and column headers shall be identified for data tables. 

8. Markup shall be used to associate data cells and header cells for data tables that 
have two or more logical levels of row or column headers. 

9. Frames shall be titled with text that facilitates frame identification and navigation. 

10. Pages shall be designed to avoid causing the screen to flicker with a frequency 
greater than 2 Hz and lower than 55 Hz. 

11. A text-only page, with equivalent information or functionality, shall be provided 
to make a web site comply with the provisions of this part, when compliance cannot be 
accomplished in any other way. The content of the text-only page shall be updated 
whenever the primary page changes. 

12. When pages utilize scripting languages to display content, or to create interface 
elements, the infonnation provided by the script shall be identified with functional text 
that can be read by assistive technology. 

13. When a web page requires that an applet, plug-in or other application be present 
on the client system to interpret page content, the page must provide a link to a plug-in or 
applet that complies with §1194.21(a) through (1). 

14. When electronic forms are designed to be completed on-line, the form shall allow 
people using assistive technology to access the information, field elements, and 
functionality required for completion and submission of the form, including all directions 
and cues. 

15. A method shall be provided that permits users to skip repetitive navigation li nk s. 

16. When a timed response is required, the user shall be alerted and given sufficient 
time to indicate more time is required. 
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APPENDIX G: SAMPLE MEMBER UPDATE FORMS 


Submit an Address 



I Submit Address J 


Edit Address 


Street 1 
Street 2 
Street 3 
Street 4 
City 
State 
Zip 
Country 



[ Update Address ] 


Delete Address 


Are you sure you want to delete this HOME address from the database? 
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APPENDIX H: SAMPLE INFORMATION DELIVERY TOOLS 


All Current News 


Test of New Civil Engineer Corp Portal 

The new Civil Engineer Corp Information Delivery Portal prototype is complete. Welcome to the site. Feel free to explore and enjoythe resource. Submit 
comment, concerns, or suggestions to LT Chris Rader at ncrader(gnps.navy.mil. 


EFA CHES ROICC Office Receives CMAA Award 

The EFA CHES ROICC office recently received the Construction Management Association of America's (CMAA) National Capital Chapter, 2001 Project 
Achievement Award for the newly constructed Glenn Warner Soccer Facility at the U.S. Naval Academy. The award is provided annually to the 
construction management entity that best exemplifies professionalism and excellence in the management of the construction process. The $4.5 million 
project is a one story 17,000 square foot building consisting of a home team wing and a visitor wing on either side of a two-story high domed memorial 
lobby. The memorial lobby is the focal point for displays and was constructed to a grade of finish to host formal functions. The wings provide coaches 
offices, locker rooms, laundry facilities, training room and shower facilities. A concession area and a ticket booth were also incorporated into the 
visitors wing. ROICC Annapolis led the project team in setting up a master schedule, developing a procurement strategy, establishing project 
performance criteria, selecting the design-builder, design development and construction of the facility. The project was delivered eight months early and 
finished by original contract completion date. The tight schedule led ROICC Annapolis to propose design-build delivery system which allowed completion 
of the project in 13 months vice 21 months to design-bid-build and use of the facility for the 2001 soccer season vice the normal design-bid-build 
approach that would have delayed its use until the 2002 season. The project will compete for the National CMAA Achievement Award due to be awarded 
August 02. 

PACDIV Completes Sewer Force Main Installation 

PACDIV and ROICC Pearl Harbor recently installed a new sewer force main from Ford Island to the Naval Shipyard at Pearl Harbor. The project, which 
required long distance, horizontal drilling in soft soil at the bottom of the harbor, will provide approximately 1,820 meters of 500mm high-density 
polyethylene (HDPE) pipe to transmit wastewater from Ford Island to the Naval Shipyard. The project will also upgrade the pumping capacity of the 
existing Ford Island pumping station project. The drilling began on February 1 and seven hours later, an equal length of 20-inch high-density polyurethane 
pipe was placed beneath Pearl Harbor waters. The excavation wasn't the longest attempted but it is important because of the difficulty keeping a drill on 
the correct path in soft soil. The effort is part of a $5.7 million military construction (MILCON) project that broke ground in December 2001 and has an 
estimated completion date of July 2003. ROICC Pearl Harbor will administer the contract. 

Seabee Memorial Scholarship Applications Due 15 April 

Do you know of someone with ties to the Seabees who maybe in need of scholarship assistance for college tuition? The Seabee Memorial Scholarship 
Association (SMSA) may be able to help. The 2002 SMSA award process is set to begin with the acceptance of scholarship applications which are due 
no later than 15 April 2002. Eligible applicants are sons, daughters, stepchildren, and grandchildren of regular, reserve, retired, or deceased officers or 
enlisted members who have served or who are now serving with the Naval Construction Force (Seabees)or Navy Civil Engineer Corps, or who have 
served, but have since been honorably discharged. The basis of award is financial need, scholastic aptitude, leadership, and good citizenship. 
Scholarships are for four-year bachelor's degrees, and are not available for part time or graduate study. The annual grant is renewable for up to four 
years provided the recipient maintains eligibility. Applications may be found on the SMSA website at www.seabee.org. Completed applications must be 
received or postmarked by 15 April 2002 and mailed to: SMSA, P.0. Box 6574, Silver Spring, MD 20916. Applicants will receive notification of 
application receipt, and subsequent results in July. 

PACDIV Breaks Ground on Environmental Project 

PACDIV broke ground 7 February on a military construction project that will ulti mately i mprove the water quality in the Pearl Harbor estuary. The project 
will construct a deep ocean outfall that will discharge treated effluent from the wastewater treatment plant at Fort Kamehameha on Hickam Air Force 
Base through a multiport diffuser into open coastal waters. PACDIV awarded the $21.7 million contract in June 2001 to Healy Tibbitts Builders, Inc., of 
Aiea. The existing outfall at Fort Kamehameha discharges into the Pearl Harbor estuary, which is classified as a water quality Ii mited segment (WQLS)by 
the State Department of Health. Under this designation, no increase of wastewater discharges to the estuary is allowed. Relocation of the discharge pipe 
to open coastal waters will eli minate discharge to the WQLS of Pearl Harbor and the associated future permit li mitations or violations. The contractor will 
install about 12,500 feet of 48-inch high-density polyethylene pipe using environmentally sensitive construction practices. Beginning at the shoreline 
near the existing treatment plant, a trench will be excavated across a shallow reef area using heavy construction equipment. The excavated material 
will be placed next to the trench, providing access for pipe installation. The new outfall pipe will be linked to the existing line allowing the treated 
effluent to be discharged into the water at a depth of about 150 feet. 
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All Current Awards 


NAVY & MARINE CORPS COMMENDATION MEDAL 

Meritorious service while serving as Facilities Management/Environmental Officer Naval Submarine Base, Kings Bay, Georgia from April 1998 to 
August 2000. Lieutenant Junior Grade Rader's exceptional performance resulted in unprecedented success as the Naval installation received the FY98 
and FY99 Secretary of the Navy environmental awards, and the 1999 state of Georgia chamber of commerce environmental leadership award. He 
orchestrated an in-house base operating services contractor and self-help resources to reduce repair parts maintenance dollars against the needs of a 
1.3 billion dollar infrastructure. While administering a 15 million dollar facilities management budget, he led the division through a revitalization period 
which resulted in increased efficiency and morale. Lieutenant Junior Grade Rader's exceptional professional ability, personal initiative, and loyal 
devotion to duty reflected great credit upon hi mself and v/ere in keeping with the highest traditions of the United States Naval service. 

Navy and Marine Corps Achievement Medal 

LTJG Andrew J. Shinka, CEC, USNR, April 2000 to February 2002. As AROICC, Marine Corps Base, Camp Lejeune, N.C., executed 20 contracts valued at 
more than $68 million and was responsible for $17 million work in place. Led the construction of the recon facility, renovation of 11 bachelor enlisted 
quarters, and completion of two new schools. 

Navy and Marine Corps Achievement Medal 

LT Russell J. Mattson, CEC, USN, June 2001 to December 2001. As Project Manager, NFESC, led the $2 million explosive handling wharf repair project 
at Naval Submarine Base, Bangor, which directly supported national strategic assets during a period of immense security and operational constraints. 
Ensured that the project stayed on schedule, within budget, and was completed with the highest standards of quality while minimizing operational 
impact. 

Navy and Marine Corps Commendation Medal 

LT Daniel W. Grippo, CEC, USN, March 2000 to November 2001. As Assistant Public Works Officer, Naval Air Engineering Station, Lakehurst, N.J., led 
134 civilians and 12 military personnel in the maintenance, repair, and construction of more than $900 million of base facilities, resulting in more than 
$1.5 million in annual contract savings and efficiencies and a 20 percent reduction in contract lead-time. Led the facility support efforts of more than 100 
base and community volunteers while saving more than $100,000 in costs and providing outstanding service for more than 400,000 visitors. 

Navy and Marine Corps Achievement Medal 

ENS Theodore J. Foster, CEC, USNR, October 2001 to November 2001. As AROICC, National Naval Medical Center, Bethesda, Md., performed admirably 
as the Acting ROICC and Acting Supervisory General Engineer in the wake of the events of September 11. Took the helm firmly in the absence of his 
supervisor and guided the office through difficult year end acquisitions while personally managing 16 high visibility construction projects valued at more 
than $21 million. 


Records 1 to 5 of 11 


Next 


Last 




All Current Orders 


LT Neil Rader to COMNAVFACENGCOMHQ WASH DC as FACPLN & PGM/ASST CIO 
LTJG Nathan Williams to NPS STUDENTS MONTEREY CAas STUDENT 
LT Manuel Hernandez to NPS STUDENTS MONTEREY CAas STUDENT 
LT Neil Rader to NPS STUDENTS MONTEREY CAas STUDENT 

LT Whitley Robinson to WHITE HOUSE M/O WASH DC as FAC CONST/SVC/SPECIAL PROGRAMS OFF-OSF 
CDR David Boone to WHITE HOUSE M/O WASH DC as FACPLN & PGM/SPEC PGM OFF WHMO M0010013 
LT Thomas Hunt to COMNAVFACENGCOMHQ WASH DC as MPWR PLN/MIL MPWR OFF 
LT Steven Blanton to COMNAVFACENGCOMHQ WASH DC as AIDE/TO THE COMMANDER - 00A 
LCDR THEODORE POSUNIAKto COMNAVFACENGCOMHQ WASH DC as FAC ENG/HD CB POL & DOCTRINE 
LT Holly Johnson to COMNAVFACENGCOMHQ WASH DC as FAC RSCH/SEALIFT SUPP & MPF(E) 

LT TUAN NGUYEN to COMNAVFACENGCOMHQ WASH DC as FAC ENG/BRAC POLICY MGR 
LT Rolfe Ashworth to COMNAVFACENGCOMHQ WASH DC as FACPLN & PGM/FLD OPS PGM OFF PAC 
LCDR Michael Arnes to COMNAVFACENGCOMHQ WASH DC as FACPLN & PGM/FLD OPS PGM OFF LANT 
LT Michael Teates to COMNAVFACENGCOMHQ WASH DC as FAC RSCH/NCF PGM OFF/DVG GEN 
LCDR Kevin Hutsell to COMNAVFACENGCOMHQ WASH DC as EXEC ASST/CDR CONT ENG GRP 
CDR MICHAEL STOLL to COMNAVFACENGCOMHQ WASH DC as FAC ENG/HD HSG PPV COORD OFF 
CDR Cameron Manning to COMNAVFACENGCOMHQ WASH DC as FAC ENG/HD PW ADVOCACY 
CDR Susan Globokar to COMNAVFACENGCOMHQ WASH DC as FACPLN & PGM/ASST DIR BUS ASSMT 
CAPT Thomas Calhoun to COMNAVFACENGCOMHQ WASH DC as FACPLN & PGM/ASST DIR FLD OPS 
CAPT Philip Dal by to COMNAVFACENGCOMHQ WASH DC as FACPLN & PGM/HD CSSO 


Records 1 to 20 of 24 


Next 


Last 




THIS PAGE INTENTIONALLY LEFT BLANK 


98 



APPENDIX I: PROJECT CD-ROM 


THE PROJECT CD-ROM CAN BE FOUND 
IN THE LIBRARY COPY OF THIS THESIS 
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